in reply to Re^2: DBI::CSV using a variable to request columns
in thread DBI::CSV using a variable to request columns

I think we had this discussion already...

I do not see how that changes the advice. There are ways to avoid some of the errors (disregarding if that is good practice), but the self-documenting part is still true.

I wonder how is this relevant

It isn't. Hence the introductory, "As an aside".

  • Comment on Re^3: DBI::CSV using a variable to request columns

Replies are listed 'Best First'.
Re^4: DBI::CSV using a variable to request columns
by LanX (Saint) on May 23, 2016 at 13:44 UTC
    > There are ways to avoid some of the errors (disregarding if that is good practice), but the self-documenting part is still true.

    Very generic ...

    In this sense: DRY is also a good practice! :)

    And less generic:

    The best practice would be a programming style/ SQL abstraction which allows defining the fields just once and automatically checks a table's integrity at compile-time.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

      DRY is also a good practice!

      So many different people ask, so i spread the idea each time. I fear linking to a writeup would be ignored, and using the same terminology each time would get boring. It even get's boring here (at the office) when i see people making the same stupid mistakes over and over again. I could wish for variety, at least. :)

      he best practice would be a programming style/ SQL abstraction which allows defining the fields just once and automatically checks a table's integrity at compile-time.

      If not for perl being the lazy coder's language, i would strongly disagree with that statement, demanding that the coder know what he is dealing with before touching it.