Shawn Webb#Python makes such great use of that horizontal real estate. /s
David Zaslavsky
Glyph@glyph @lattera Indeed. And in fact, now that I take a closer look at that code, there are some *really* inadvisable formatting choices in there. Including cases where the author was actively fighting against the way #Python normally encourages one to write code.
Not that I think this is what actually happened, but if someone specifically decided to create an example of how you can write code that's "properly indented" but still badly formatted and organized, I could see them coming up with something that looks like this.
C.Agreed. That level of indentation is an almost sure indicator of code that needs to be refactored, due to bad design.
And as you say, it's true regardless of the language. People were writing badly structured code with excessive levels of indentation before we were born, and will be long after we're gone.
thedæmon (Clay Ayers) [he / him]hahahahahaha, that would annoy me to no end.
Cybarbie@lattera #hottake Speaking as a person from the late 1900s and pioneer of early computing I do not understand the obsession with having 80CPL. You have a 4k screen for goodness sakes! Unless you are the copyparty guy I do not get why you would not want to use it. Even when we had 80 or 132 I would always choose longer on my VT whatev. Maybe optimal scan has changed in the smartphone era. 80 was a hangover of the old punchcards. I feel that code is intentionally bad including the weird inlining.
Speed demon 🇪🇺 🇳🇴🇺🇦🇵🇸@hakona @lattera I guess you are welcome to your wrong opinion. Newspapers are hard to read. They have tiny print in narrow columns because of how they were set by hand. No true coder would want 50CPL. The optimal scan line length for programmers who have to read quickly is at or above 80CPL numerous typography studies suggest. I can scan a 132CPL line fine but I suppose if you have only ever read the 80CPL fascism that would be difficult. And don't get me started on 'variable name or prose'
Jonathan Hartley@lattera I don't know about that. This is the code trying to tell you something, right? If you don't like huge indents, then don't use such huge cyclomatic complexity. Even with the most hurried and superficial refactor it fits just fine in 80 character lines, and in reality I'd make better use of Pythonic idioms and features to simplify and improve readability way more than this...
@lattera Like, some of these functions feel like they might benefit from being methods on classes, which eliminates many of the passed around variables. A lot of the cleanup actions should probably be happening in context managers. The exceptions could probably be changed from a "catch, log and carry on" style into a "raise and forget" style. All of which, and more, would render the core, inner part of the code more succinct and readable.