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