Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

(jcwren) Re: My code and your stupidity don't mix!

by jcwren (Prior)
on Dec 06, 2001 at 19:15 UTC ( #129928=note: print w/ replies, xml ) Need Help??


in reply to My code and your stupidity don't mix!
in thread Would you use 'goto' here?

Since I'm willing to bet your paycheck that I have a few more years in the software industry that you, allow me to point something out:

A software shop does not want to have to hire the top 5% of the skill pool just to do code base maintainence when you leave. You also don't probably don't want to spend the rest of your work career at that company maintaining a project you wrote 5 years ago.

To this end, it's well and fine to use out-of-idiom methods when absolutely necessary, but not just because you can, or because they're cute. An *experienced* programmer recognizes when to write for efficiency (and saving .0001 CPU seconds off a job that runs once a week hardly qualifies), and when to write for maintainability.

Some languages support the ability to write obfusicated code more than others. Perl outshines C in this respect, since Perl is a richer and more complex language. If the next guy that comes along to make some changes to your code has to track you down across the country to ask about how something what was done, that doesn't necessarily make him stupid. It may make him less skilled, but it's also a reflection on your inability to write for maintainability.

Try getting involved in code reviews. If you have 5 people on the team, odds are they will not all have the same skill levels. If 2 or more agree that your code is obtuse, perhaps you should consider your style.

The inability to write for maintainability costs a company money. You may have saved 10 minutes thinking about how to do it, but if it took 3 days for someone else to figure out it's supposed to work, you've burdened the company with your 'coolness'.

Let me take another tack. Let's say you told me "I can read English". So, I write you a letter in English. No problems, right? Well, you start complaining about my use of the words with more than 6 letters. They're too difficult. You've never seen them. You don't like them. (And, yes, I've received this complaint before!) Should I not use a standard part of the language you have said you speak solely because you don't want to make good your assertion?!?

This is a bad assertion, by the way. There are plenty of phrases I can write that will send you to a dictionary to figure out what I mean. Unless your goal is to complicate communication, there's no point in using obscure words. If you're trying to be understood, you don't use words that only see print when a new dictionary is released.

A whole armamentarium of devices to create an illusion of real life -- Kenneth Rexroth

--Chris

e-mail jcwren


Comment on (jcwren) Re: My code and your stupidity don't mix!
Re: (jcwren) Re: My code and your stupidity don't mix!
by dragonchild (Archbishop) on Dec 06, 2001 at 19:39 UTC
    I have, in no way, said that obfuscated code is a good idea. I have also not said that using undocumented features of Perl is a good thing to do. I'm talking about lesser-known features, like goto &foo, that are documented and correct to use in certain situations.

    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;

        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;

        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.

Re (tilly) 2: My code and your stupidity don't mix!
by tilly (Archbishop) on Dec 06, 2001 at 21:31 UTC
    While I would cheerfully bet your paycheck that you have been in software longer than I have, I think there is a bit of a 2-way street between keeping to what other people know, and teaching them more about the tool.

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://129928]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2014-08-30 13:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls