[Gllug] More Microsoft patents

Alain Williams addw at phcomp.co.uk
Wed Feb 12 15:25:54 UTC 2003


On Wed, Feb 12, 2003 at 03:01:49PM +0000, Doug Winter wrote:
> On Wed 12 Feb Jason Clifford wrote:
> > On Wed, 12 Feb 2003, Doug Winter wrote:
> > > Most languages explicitly avoid this problem by only allowing named
> > > variables, and using strict scoping rules.  These give the languages are
> > > more verbose "narrative" quality that makes it far more maintainable.
> > 
> > Exactly as you do in perl with the use of the "Use strict" pragma.
> > 
> > I don't know of any serious perl coder who would write anything without 
> > it.
> 
> Yes.  This doesn't avoid the implied variable business though.  $_ and
> @_ and friends.
> 
> > > If you have to put a line of comments for every line of code to
> > > explain what it means, then that code is bad.
> > 
> > And this is relevant how? Nobody is advocating that.

Quite. IMHO you should comment 'blocks' of code -- what it's purpose is,
possibly why it does it the way that it does and why it doesn't do it some
other way (because the other, seductive, way doesn't work).

Comment individual lines if they are non obvious - because of syntax,
interractions with global variables, ...

> I may be misunderstanding Alain's position, however this is what he
> wrote:
> 
> Alain Williams previously wrote:
> > Individual statements can be hard to understand in some languages -
> > this is  +where perl can be difficult - but a comment saying *what* it
> > does is all that is needed.  +If you need to change it, you take the
> > time to work out *how* it does it.

$_ & @_, etc, are part of the perl syntax. If you can't see their implied use
then you are looking at a program that is too complex/... for you.
Every programmer has an ability level at which they operate: this will
vary depending on language and application type. It corresponds to the
experience that they have had. Trying to maintain a program that is beyond
your level will be hard - but if it isn't too far above your level, you will
(hopefully) learn from the effort.

My point is that clarity is more a result of the quality of the mind of the
original programmer than the choice of language.

A corrollary to that is that, IMHO, much code (commercial & open source/...) is
poor quality - badly laid out, not commented adequately & the program not documented
for the end user.

-- 
Alain Williams

#include <std_disclaimer.h>

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list