Collective memory

Walter Bushell proto at panix.com
Sat Jul 12 15:37:34 EDT 2003


John Roth <newsgroups at jhrothjr.com> wrote:

> "Abigail" <abigail at abigail.nl> wrote in message
> news:slrnbgt6ls.ab5.abigail at alexandra.abigail.nl...
> > Walter Bushell (proto at panix.com) wrote on MMMDC September MCMXCIII in
> > <URL:news:1fxw51u.2b4m6zc39wulN%proto at panix.com>:
> > ++  Charles Richmond <richmond at ev1.net> wrote:
> > ++ <Snip>
> > ++ > int  *p, x, y;
> > ++ >
> > ++ > then:
> > ++ >
> > ++ >     y = x/*p;
> > ++ >
> > ++ > is quite different from:
> > ++ >
> > ++ >     y = x / *p;
> > ++ >
> > ++ > The first way, "/*" will begin a comment...the second way,
> > ++ > you get the integer "x" divided by the integer pointed to by "p".
> > ++
> > ++  Ouch!! That is one reason code coloring is *important*.
> >
> > Nope. That's a reason why code colouring is evil. If you write code,
> > and it isn't clear what you mean without the use of code colouring,
> > you did something wrong. Your code shouldn't rely on a specific code
> > colouring scheme to be understandable.
> 
> This assumes that someone reading the code is going to be using
> a brain-dead editor. We need to get beyond that some day, and
> assume that people are going to be using decent tools.
> 
> John Roth

Of course, we have to consider color blind programmers.

Well we shouldn't have a single space making such a difference,
particuarly when white space does not usually matter, in an arithmetic s
tatement no less. Division by the integer pointer to by p and the
beginning of a comment in something that is rather large.

Something like this 

  y = x/*p++ +expression;

Above will be caught usually by results I presume

However, how strings are implemented in quoted strings and the standard
library is a nightmare.  

> >
> > All in my opinion of course.
> >
> >
> > Abigail


-- 
The last temptation is the highest treason: 
To do the right thing for the wrong reason.  --T..S. Eliot

Walter




More information about the Python-list mailing list