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-le...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/T2UVXLFJ3OUJDZTGLIJOLOYEQOGF53DC/
Code of Conduct: http://python.org/psf/codeofconduct/
