Allowing comments after the line continuation backslash

Roy Smith roy at panix.com
Sat Nov 6 13:44:38 CET 2010


In article <ib2vrb$3eq$4 at lust.ihug.co.nz>,
 Lawrence D'Oliveiro <ldo at geek-central.gen.new_zealand> wrote:

> In message <8jd3m9Fr55U7 at mid.individual.net>, Neil Cerutti wrote:
> 
> > On 2010-11-03, Ben Finney <ben+python at benfinney.id.au> wrote:
> >
> >>     styles = [
> >>         ("normal",      "image",     MainWindow.ColorsNormalList),
> >>         ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> >>         ("selected",    "select",    MainWindow.ColorsSelectedList)]
> > 
> > Agreed, except cute stuff like putting those three items in
> > columns is just as bad.
> > 
> > Code should be utilitarian rather than ornate, Shaker rather than
> > Victorian.
> 
> Tufte’s concept of “chartjunk” could perhaps be extended to “formatjunk” or 
> “prettyprintjunk”.

Not at all.  Tufte is all about making data easy to understand visually.  
The chartjunk he rails about is colors, shadows, 3-d effects, etc, which 
make a chart "look pretty" but don't add to comprehension.  If you take 
out the extra whitespace, you end up with this:

> >>     styles = [
> >>         ("normal", "image", MainWindow.ColorsNormalList),
> >>         ("highlighted", "highlight", MainWindow.ColorsHighlightedList),
> >>         ("selected", "select", MainWindow.ColorsSelectedList)]

which I think is more difficult to scan visually.  In the first example, 
I can see from the overall layout, without reading a single character of 
punctuation, that this is a sequence of groups of three items.  That's 
harder to see in the second example.

Likewise, if I want to know what kinds of things are in the second field 
of all the items, it's easy for me to visually scan down the second 
column in the first example.  To do that in the second example is much 
more difficult.

If you want to talk about "codejunk", my biggest concern here is the 
things in the third column.  They all start with "MainWindow.Color", and 
they all end with "List".  Thus, those bits of text add bulk, and no 
useful information.  It would be even more readable by doing:

> >>     styles = [
> >>         ("normal",      "image",     Normal),
> >>         ("highlighted", "highlight", Highlighted),
> >>         ("selected",    "select",    Selected)]

which, of course would require some more code elsewhere to define the 
new names.  Whether this makes sense in the context of the overall 
codebase is an open question, but taking the table in isolation, it 
certainly improves the readability.  Tufte would approve.



More information about the Python-list mailing list