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/JSCI22... 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