

shlomif_tech

[ shlomif ]

On the Modern Perl Books blog, chromatic wrote a post titled "From Novice to Adept: On Answers to Smart Questions" where he mentions my comment to a previous feature of his there. I am flattered that chromatic decided to expand upon my comment. Quoting my comment: I agree with you about it. However, idioms are nice and dandy, but naturally, when going on IRC, one can often open the Pandora box of the colour of the bike shed argument. For example should it be: Person->new( first => "Sophie", 'last' => "Cohen", birth_year => 1977, ); Or: Person->new({ first => "Sophie", 'last' => "Cohen", birth_year => 1977, }); (with a hash ref) I tend to think the second option is better because it's probably a bit faster (not that it matters a lot), and because it will warn about an "odd number of hash elements" earlier, but there's a lot of code on CPAN out there that uses the first option, because it involves somewhat less syntax. In one of my modules, I supported only the second option, and a programmer who was after my T-shirt offer, implemented convulted code to have it either with a single hash-ref or flattened into @_, which I had to reject. Naturally, this is just the tip of the iceberg. Brace indentation, placement of HTML opening and closing tags, whether HTML should be nicely indented (even if generated by a server-side language), or instead occupy as little space as possible, whether you should sub-class sub new {... } or sub _init {....} etc. etc. are all a matter of much debate, and they are pretty much a bike shed colour's argument (while they often do have some points for and against). I think it's important for a beginner (in Perl or in any other language) to distinguish between such minor matters and non-idiomatic code, and that it is even more important for an expert to see past his own preferences for the bike shed's colour when helping newcomers. chromatic discusses it in the page above, and gives some advice for newbies who want to avoid getting confused from such discussions on personal style and conventions. Often, matters such as those of indentation and whitespace or placement of braces have some good and valid arguments either way, but they are still a bike shed colour argument, and as such should be either enforced globally by the project or workplace, or alternatively a programmer can do what they prefer on their personal project.