It should be clear in respect to what yields the fastest development and
maintenance time for the environment in which you are in, while still
maintaining quality.  I am specifically being vague about the "who" I am
talking about, because it's not about the who, but the concept of
maintainable code, and cost effective maintenance.

Yes, some people will have to learn.  And foreach() is something specific
to Perl, that I think is good.  Some concepts in Perl don't exist in other
languages.  That's a given.  And if a new person has to get up to speed,
then they will have to take the time to do so.  Avoiding the advantages of
a language wasn't my point.  From way back near the beginning of of the
coding practices portion of the thread, what was being singled out was
obscure coding; ie. taking 10 lines of code and finding a way to crunch it
into one, very difficult to interpret line.

It's not a matter of whether Person X or Person Y thinks the code is
clearer, but rather whether the department Z, over the number of years the
code will need to be maintained, will see it as "clear", where "clear"
equals minimized maintenance and development costs.  This is not something
that can be put into a specific case, as it's more a general measurement.

In reference to an individual, it means that the individual doesn't have
to spend more time on the same high level concept of execution.  If person
A spends 5 minutes writing code i, and 6 months later must spend 20
minutes to figure out what he did before changing it, because it was coded
obscurely in the first place thats bad.  A better scenario would be that
Person A spent 8 minutes coding a longer but more clear function, and only
10 minutes 6 months later... especially if in another 6 month the code
must be revisted again.

I'm sure you know what I am talking about.  Trying to pick it down to the
nitty gritty really only detracts from the general point.  A person (A or
B) should make sure that it's pretty easy to figure out what is going on
when either they (at a later point) or another person has to go look at
the code.  It's not about the fundamental syntax, but rather the coding
style and standards... things like, indentation, variable names, function
names, 1 phrase (ended with semi-colon) per line (maybe a few rare
exceptions)... It's about the code being clear, not whether someone knows
the syntax.  And in a larger situation with more programmers, consistency
of that standard across the code is also a good thing (where possible).

Heck, I don't even remember how we got down this path from mod_perl not
letting Apache start.  heh.

Cheers,
-Alex


On Mon, 15 Apr 2002 09:34:23 +1000, Ken Williams wrote:

> 
> I should have been more clear.  I think you're supposing that 
> there's some "lingua franca" in which people can program and all 
> be understood by each other.  I'm proposing that no such thing 
> exists.  Furthermore, there is code such that:
> 
>    * Person X thinks code A is clearer than code B, but
>    * Person Y thinks code B is clearer than code A.
> 
> So who, in that case, do you try to satisfy?  The answer simply 
> depends on what kind of people are going to be working on this 
> project.  Here's a really simple example:
> 
>    Code A:
>         my $i;
>         my $n = scalar @array;
>         for ($i = 0; $i < $n; $i++) {
>           $array[$i]++;
>         }
> 
>    Code B:
>         foreach (@array) { $_++ }
> 
>    Person X: a C programmer with no Perl experience
>    Person Y: an experienced Perl programmer
> 
> 
> It sounds like you're in a corporate environment where people 
> are going to be coming and going, and you can't depend on any 
> familiarity with Perl.  Most unfortunate, but I guess you've 
> figured out how to deal with it.  In other situations, the 
> strategy would be different.
> 
> 
>   -Ken
> 
> 


==================================================
  Email:  [EMAIL PROTECTED]
  Website:  http://www.beardeddragon.org/
==================================================


Reply via email to