If you do code reviews and 40% of developers find your code obscure, then possibly you do need to work on making your code clearer. OTOH possibly you need to work on educating them so that they understand your code, and work more effectively themselves. I think it is good for a company to decide that its standards for new employees include a learning curve, and that learning curve shall include mastering a set of features which may or may not be in wide use elsewhere.

I think that is particularly true with a language like Perl where most people who claim on their resume to know it actually know it very poorly.

Note that I am not saying that all problems are to be solved by teaching your fellow co-workers. There is a balance to be reached between using features that make you personally more productive, and keeping to what is generally known.

If you do code reviews and 40% of developers find your code obscure, then possibly you do need to work on making your code clearer. OTOH possibly you need to work on educating them so that they understand your code, and work more effectively themselves.

There's a sampling trap here that I've seen many organizations fall prey to, which is to have the top 50% of developers be the principal (or only!) participants in code reviews. Big mistake if you're vetting code for maintainability. The top half may have no problems with idioms that will stump others. I've seen this happen with Java and C++, as well as Perl.

Interesting point.

However I think that good developers who are on the lookout for it can flag constructs which they understand but they think others might not. Furthermore good developers are more apt to notice the maintainance implications of seemingly innocuous constructs. Therefore if you have good developers who are concious of these points, and who have exposure to what others know (eg through assisting in training, answering questions, etc), I think they can take into account the bottom half in considering maintainability for code reviews.

But still I have to wonder at the value of doing a modified usability study to find maintainability implications. Take code from programmer A, hand it to programmer B, and have experienced observer C take notes as B talks through trying to figure out A's code...

UPDATE
Inserted an important "not" that Corion caught.

Here's an example - would you say that using the Schwartzian Transform or Orcish Manauver is "obtuse"? Yet, one uses map liberally and the other uses ||=, which is a lesser-known feature. (It receives less than one page in the 3rd ed. Camel book.) If I were to take the Orcish Manauver to a code review in most Perl shops, 2/5 would definitely vote it's obfuscated! Yet, I hope you're not advocating that the Orcish Manauver is unmaintainable.

Yes, you have a number of years more in the industry. However, nearly all my years have been rewriting badly written code and being forced to make it more maintainable in order to do anything with it. My "coolness" may cost the company three days, but someone else's "stupidity" just cost the company my last month's of work.

I'd much rather someone use lesser-known features, but wrote good code, than someone use the easier 50% and write it badly.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

What, if you would enlighten me, is an Orcish Maneuver? There are only mentions of it by name on the site, but no examples...

The Orcish Maneuver is a term coined by Joseph Hall in his book "Effective Perl Programming" (co-authored by merlyn). Here's the essence of it:

my @sorted = sort {
    ( $times{$a} ||= -M $a ) <=>
    ( $times{$b} ||= -M $b )
} @old_array;
[download]

The "orcish" (a bad attempt at humor: "or cache") maneuver basically caches the results of an expensive lookup using the ||= operator. This operator says, in the above code, that $times{$a} will be evaluated or, if it is false, set it to the value of -M $a. (-M is the file test operator for last modified time). This allows you to cache the results of -M rather than call it every time. This has the same effect as:

for ( @old_array ) {
    $times{ $_ } = -M $_;
}

my @sorted = sort { $times{$a} <=> $times{$b} } @old_array;
[download]

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

My point exactly.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.