Re: (3) Ternary confusion

[arturo]

I'm not going to quibble with the basic thrust of your advice, but the following quote struck my eye:

The above code is obfuscated seemingly for the sake of obfuscation.

What leads you to say that? Because it uses the ternary operator? The first thing I noticed about the code is that it put each significant chunk on its own line. That hardly seems like the practice of a determined obfuscator. Apart from the issue of whether or not a given developer is familiar with the ternary operator, it boils down to :

$db = [connection specification] or die;

which is plain 'ol idiomatic Perl.

There are a number of reasons one might write code like that, having nothing to do with obfuscation. Perhaps the original author liked the terse idiom and compensated for it by formatting the code the way s/he did. Maybe s/he had five minutes and somebody asked her/him to make the script use a different connection if it was running on a specific server.

Of course, if you're going to rewrite it for later expansion, you might as well move the connection selecting code off into its own subroutine or, if it's complex enough, module. But I think we should all be aware that developers don't always have the time to develop code like that right from the very start -- especially when you don't know whether your code is going to be in use two weeks after you write it, which is a distinct possibility.

[dragonchild]

Maybe it's because
• I've had to write the same DBI connection code over and over
• I've had to have a $dbh available in a bazillion different places
• I've needed config files for other reasons
• I'm just really paranoid about usernames/passwords in code
but I find that making decisions in code about which database to connect to based on an environment variable is obfuscated by its very nature. The ternary operator is not obfu. I personally don't use it a lot (kinda like I don't use select alot), because I abstract decisions away to the entity that needs to make the decision. (I'm a refactoring-nazi, actually.)

I'm going to take issue with your last paragraph. Any developer worth their salt should have a number of modules in use that allow for reuse. For example, I have a set of tools that would allow me to do almost any one-off task without writing much code for database connections, configuration, and the like. And, it's almost quicker to write it factored out than it is to write it as one big blob. Why? Because it's easier to verify that your code which may only have one chance to be executed will do it right. Because you're never noticed when you succeed, but you're in the spotlight if you fail. Developers will always have time to develop correctly, if they plan as if they will need to do so in the next hour.