Re: Long names are doom ?

[Pete Thompson <blackpete@nowhere.somewhere.anywhere.com>]

On Wed, 06 Jun 2001 12:30:26 +0100, David Gillon <david.gillon@baesystems.com>
wrote:

>Explicit, readable coding has value even when being read by the most
>experienced of software engineers. Consider the case of a safety
>critical system under review by an external auditor prior to
>certification. It's vital he be able to review the system in as thorough
>a manner as possible in the time available, yet he may be completely new
>to your coding standards and practices. The logic of a decision needs to
>be clearly laid our for him, not something he needs to delve into the
>musty depths of obscure documents for or to seek information on from the
>original coder (especially if the original coder is in a substantially
>different timezone). Equally, someone may have to fix your code twenty
>years down the tracks, when the original coding team and the rationale
>behind their decisions may have long since vanished (or walked in front
>of a bus...). 
>
>Explicit pays, maybe not now, maybe not directly, but in the end its a
>worthwhile investment.

Yes, I quite agree.  The point I was trying to make is that there are varying
levels of "explicitness" allowed in different industries.  In your example, a
critical system designed to last years, you'd be crazy to be non-explicit.  

However, if you're working in an industry where speed and optimization is king,
then you sometimes simply don't have a choice and you're forced to write
optimizations that may look cryptic.  However, in such cases you should be sure
to COMMENT it, and explain what it is and how it works.

I think that people misunderstand me on one thing:  I am not at all arguing
against the use of comments.  The code itself doesn't have to read like an
essay if it's well commented. 

However, if I'm using a fairly standard API, then it's not up to me to write
code that also teaches a newbie programmer how the API works.  That's not my
job.  My job is to do my job, and to explain why and how I'm doing my job, not
teach others how to code.  If a newbie programmer has to read my code, then
there are two requirements expected from him/her:  know the language, and
understand the API.  I don't think this is too much to ask from any new
programmers.