Re: Two simple code style advice questions

[LanX]

After working for a while with Perl "programmers" which were mostly converted PHP-hackers and quickly trained sociologists (both with an experimental approach to Perl) I got very cautious about production code. (Especially because everybody was allowed to change and commit into any project... )

So there is a personal preference and a $work preference...

Part 1

So clearly (a) is better as long as speed doesn't matter, even for me the $_ => 0 part evidently signals a hash assignment to my visual cortex. And this construct is easily changed to other meanings.

The only exclusion to that rule may be this idiom @ntests{@tests} = () to assign undef.

Anyway in aforementioned work context even map was risky.¹

So maybe

   my %ntests;
   $ntests{$_}=0 for @tests;

would cause the least problems.

Part 2

For me (a) is an obfuscation hack. It goes to deep into brain loops about numeric type casting.

So this time (b) for me.

At $work (where the word "ternary" provoked empty glares¹) maybe rather:

   my $mol = "";
   $mol = "forty two" if $n==42;

HTH! :)

¹) It hurts, I know!

[BrowserUk]

At $work (where the word "ternary" provoked empty glares)

I cannot imagine any other profession where the experience practitioners would 'dumb down' their output to accommodate the inexperienced.

Can you imagine:

1. A barrister using the phrase a judicial mandate to a prison official ordering that an inmate be brought to the court so it can be determined whether or not that person is imprisoned lawfully and whether or not he should be released from custody rather than a writ of habeus corpus because his apprentice or legal assistance might not understand the latter?
2. A doctor using heart attack instead of acute myocardial infarction; because his interns might not be familiar with the latter?
3. An architect referring to a sticky-outty, stubby bit of wall at 90° to the main wall rather than buttress in order to placate, his apprentice?
4. A composer re-writing his music to avoid all sharps and flats because they make life difficult for air guitarists?

The short answer (I sorely hope), is a profound NO!.

So why do experienced programmers who do understand -- none of them ever admit to having problems understanding themselves -- these hardly difficult concepts and constructs, advocate 'dumbing them down' for the sake of those programmers who's education is formative?

And whatever justifiction you might offer in reply; STOP. And think. Because there is no logical justification.

If you dumb down, they will never learn, which is in nobody's interest.

If the first time they encounter a construct they do not understand, they do not ask for (or look up) clarification, then they deserve to be admonished strongly. If they do it a second time; they should seriously consider a different career. If their mistakes made as a result of their lack of understanding make it into production, their mentor deserves admonishment. Or the system that allows un-mentored code to get into production, needs urgent review.

Advocating the dumbing down of code, as a substitute for (requiring) proper education, is itself dumb.

[LanX]

As a freelancer you don't insist on giving blow jobs, when the customer only wants to pay for spanking!

PS: yes s/freelancer/prostitute/ ;-)

[Anonymous Monk]

You have a point, but I think you're taking it a bit too far (and yes, I did stop and think).

First of all, "dumbing down" is an awfully harsh term here. The for loop and if statement solutions that LanX suggests are functionally equivalent to any other solution that has been proposed, and there is no meaningful performance penalty.

To me "dumbing down" would be avoiding powerful language features (such as regexes) because they are confusing. That would be dumb. But this is nothing more than a benign style preference.

Perl's allowable syntax is so vast that anyone who wants to write sane code will only use a subset of it. Maybe avoiding map and the ternary operator is going too far. But as much as I love map, I have to admit that I am usually using it "because I can" not because it is clearly advantageous in my code. And as much as I love the ternary operator, it has its pitfalls (such as the can-be-used-as-an-lvalue-making-assignments-have-unexpected-behavior pitfall).

Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

[BrowserUk]

But this is nothing more than a benign style preference.

Sorry, but I think you must have missed the bit of LanX's post that I quoted, so I'll re-quote it here:

At $work (where the word "ternary" provoked empty glares)

My post was in specific reaction to that statement. (Though to be fair to LanX, it could equally have been applied to a lot of Re: Two simple code style advice questions).

I have no problem with people choosing a particular style -- well, not too much anyway :).

I do have a problem with programmers "simplifying" their preferred style under the justifiction that those that come along after them may not understand it.

And I have even more problems with people advocating that everyone should dumb down their code in order to make it accessible to the lowest common denominator of programmer skill sets. Be that done under the auspices of 'best practices'; or 'modern Perl'; or Perl::Critic; or any other set of non-personal rules or guidelines.

And the reason I have a problem with it is because it demeans the dedication and perseverance that it requires for even half descent programmers to acquire the education and skills that make them such. It encourages (and even enshrines!) the viewpoint amongst those non-programmers and 'did a bit once many years ago' semi-skilled programmers (think:managers and personnel types), that all too often control the purse strings (think:recruitment and education budgets), in our industry, into believing that programming is easy and that any ol'post-grad that had sufficient attendance on a half-credit basic programming or CompSci course, is sufficiently skilled to design, write and maintain code.

Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

Sorry again, but that just doesn't make sense.

Anyone who needs to read your code with a view to understanding it well enough to base business decisions upon that understanding, is acting in a professional capacity. As such they should be sufficiently educated to understand the code, or willing to expend the effort to acquire that education.

And if they are not making business decisions based upon their understanding of the code, what do you care if they do not understand it?

I'm most offended by "Perl, because of the nature of the language,". The fact that Perl is an accessible language -- designed to be so -- should not prevent the recognition that is a fully capable professional language usable for the construction of highly complex software.

And just as with any other profession, the products of the programmer's skills require a certain level of education and/or aptitude to understand before you can hope to safely maintain, modify or extend them.

Nobody would deny the non-programmer sysadmin from learning just enough Perl to allow him to knock up a few scripts to simply his daily workload; or the hobbyist webmaster from learning enough to add a bit of dynamism to his website. But trying to use that ease-of-entry of the Perl language as reasoning that professional Perl programmers should code down to their level is just crazy. Wrong at every level.

[Anonymous Monk]

sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

Funny, I can't envision that as a valid scenario -- if you can't read it, don't try to modify it ... educate yourself