Thanks Rob.

You've broken a number of "rules" code code formatting there ;-)

A big one is aligning things vertically, which, as a rule, I like. but this example does really push things out away from each other, so I'm not so sure.

I found that the original looked like heck when I first opened it in my editor -- once I made the window wide enough it was better, but still pretty stretched out.

Just for fun, here it is after being run through Black (which I don't usually use ....) -- but I think it looks better that way.

Also -- my first thought looking at that was that it could really benefit from the pattern matching :-)

And my second thought was that there could be a whole other pattern used here -- I usually find long chained elifs can be better expressed as a dict selection, or subclassing, or ...

But not seeing the rest of the application, maybe maybe not in this case.

if ch == "B":
    self.ToggleBackgroundColour(event)
elif ch == "C":
    self.ChangeCommonChars(event)
    return
elif ch == "D" and len(Areas) > 1:
    self.DeleteArea(event)
    return
elif ch == "F" and __debug__:
    self.Info(event)
    return
elif ch == "I":
    self.ChangeImagesToScroll(event)
    return
elif ch == "J" and self.NUMBER_OF_IMAGES == 1:
    self.ChangeJustification(event)
    return
elif ch == "L":
    self.ToggleShowLabels(event)
elif ch == "M" and MaxNumberOfImages > 1:
    self.ChangeNumberOfImages(event)
elif ch == "N" and CanZapImage:
    self.Rename(event)
elif ch == "R" and not (area.Dynamic | area.IsTour):
    self.ToggleRandom(event, 1)
elif ch == "S":
    self.ToggleSets(event, 1)
elif ch == "T":
    self.ChangeTimer(event)
    return
elif ch == "U" and not (area.Dynamic | area.Random):
    self.ToggleIsTour(event, 1)
elif ch == "V" and OnAnImage:
    self.WindowsPhotoViewer(event)
    return
elif ch == "W":
    self.ToggleWrap(event, 1)
elif ch == "Y" and not (area.Random | area.IsTour):
    self.ToggleDynamic(event, 1)
elif ch == "Z" and CanZapImage:
    self.Zap(event)
elif ch == "A" and not (area.Dynamic | area.IsTour):
    self.ToggleRandom(event, 1)
# Alt-R doesn't always work for some reason, so we give Alt-A as an alternative
else:
    event.Skip()

 

On Fri, Feb 12, 2021 at 1:46 AM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote:

On 08/02/2021 00:39, Brendan Barnwell wrote:
> On 2021-02-07 09:59, Christopher Barker wrote:
>> All that being said, it's not that big a deal, and I personally don't
>> try to limit to 80 chars per line anyway -- preferring 90 or 95 -- I
>> haven't used a VT100 in decades ....
>
>     To be honest I find it kind of ridiculous that people are still
> worrying about line lengths in this day and age.  It's especially
> strange that people will talk about how a proposed feature interacts
> with relatively sophisticated editor/IDE features like syntax
> highlighting and autocompletion, yet still have no problem working
> with editors that are woefully limited on a much more basic feature. 
> It's called line wrapping.
>
>     We as humans should not be concerned with how long LOGICAL lines
> are until and unless it actually impinges on our ability to comprehend
> them.  The appearance of the VISUAL line should not enter into our
> decision-making because that's a matter for the editor displaying the
> code.  There's no reason not have lines that are 200 or 300 or even
> 1000 characters long if you want to (for instance for a long string
> literal); it's the editor's job to take a semantically-motivated set
> of lines and indentations and display them attractively.  Then if
> different people have different preferences they can set their editors
> to different line widths and see the code in their preferred format. 
> Editors that don't support such features need to be fixed and we
> shouldn't continue to enable them by insisting that people distort the
> semantic structure of their code to fit arbitrary guidelines like 80
> or 95 characters.  A person should insert a line break whenever they
> think it's a good idea for semantic reasons (e.g., separating
> statements) and not insert any when they don't think so, and leave the
> rest up to the editor.
>
+1.
Keeping lines to 80 characters makes it easier to understand *individual
lines*.
But allowing fewer, longer lines makes it easier to perceive *the code
structure as a whole*.
I want to illustrate this with a bit of actual code from one of my
programs.  It uses lines up to 102 characters including 12-space
indentation.  Oh, and it breaks another Python shibboleth - not having
multiple statements on one line.  Apologies, it looks horrible in an
e-mail with the spacing all mucked up, so I have put it in an attachment
(a plain ASCII file).
IMHO this is a piece of well-written, self-documenting code that I would
find much harder to grok or look things up in if were laid out
differently.  YMMV .  In fact if it were laid out differently, I would
want to document it, and the documentation would be a table that looks
very much like the code "as is".

Rob Cliffe



_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSCI223RQWSOABLTQ7OKEBQMOHJGUXBO/
Code of Conduct: http://python.org/psf/codeofconduct/

--

Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython