[chirp_devel] Is FLAKE8 line length 80 still appropriate?
Is there any particular reason why we're sticking to the FLAKE8 default of 80 character lines? The first thing I always do is change it to 160. 80 is just too tight for expressive names. Every single line ends up getting continued. Sometimes you even have to do battle with the enforced "visually pleasing" indents that can reduce the functional line length to 40 or less.
On 18/5/23 07:54, Craig Jones via chirp_devel wrote:
Is there any particular reason why we're sticking to the FLAKE8 default of 80 character lines? The first thing I always do is change it to 160. 80 is just too tight for expressive names. Every single line ends up getting continued. Sometimes you even have to do battle with the enforced "visually pleasing" indents that can reduce the functional line length to 40 or less.
I might be strange, but I still greatly prefer 80 columns, even on a "wide" display. My own projects break lines at 78 characters. Code in C also uses tabs (with 8-space stops) for indentation.
On my laptop, I run 1366×768: a limitation of the panel. Terminus 12 font lets me see 165 characters before the line wraps. If the line wraps half way through a word, that is harder to follow than a deliberate split made intelligently by a human at some sensible point.
I could upgrade the laptop to one with a "Hi-DPI" display, but then I'd probably have to increase the font size to compensate, I'll see about the same amount of text. (I've tried a 4K display that's the same dimensions as this laptop display… best case is no better than what I have, worst case is: "get the microscope!")
On my desktop I run a "full HD" display with a much larger display, but effective screen area in terms of characters isn't a lot bigger. I might see 180-200 characters.
At my workplace, I have a newer laptop with an external monitor that's much higher resolution (not sure exactly what resolution but greater than full HD), I see more, but it's probably in the order of about 250-300 characters.
Now at this point you're saying, this is all wider than 160 characters, what's the problem?
My memory is not the best, and I find it useful when writing a piece of code, to refer to the code or data it is interfacing with to ensure I get references correct.
A major part of my workflow is to either display two windows side-by-side with different but related files, or the same file "split vertically" to show two different parts of the same file side-by-side. This enables me to refer to one piece of code whilst working on the other.
Dual monitors don't work as I am too used to a single-monitor workstation, having spent much of the first 20 years of my computer-using life with machines that were either single-monitor, or could at best mirror output to a second monitor. I also use a graphics tablet as a pointing device, and dual monitors seriously screws up the aspect ratio of a tablet.
Linus Torvalds used to recommend 80 characters and tab-indentation in the Linux kernel because he argued that if your code was getting constrained to the right-hand edge (in his words "more than 3 levels of indentation"), your functions were probably getting too complex and should be split up:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu...
Python isn't C, but I think the same logic holds true: if your functions/methods are so deeply nested that they're literally marching off the right-hand margin of your editor, a re-factoring might be a good idea. You can try "fudging" things by setting indentation to 2 spaces, but it doesn't make the program any more "clear" at a fundamental level.
But, I'm one person, and as I said before, a strange one at that.
Regards,
Linus Torvalds used to recommend 80 characters and tab-indentation in the Linux kernel because he argued that if your code was getting constrained to the right-hand edge (in his words "more than 3 levels of indentation"), your functions were probably getting too complex and should be split up:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu...
Python isn't C, but I think the same logic holds true: if your functions/methods are so deeply nested that they're literally marching off the right-hand margin of your editor, a re-factoring might be a good idea.
Yep, this is how I feel about it. Python's forced indenting even helps to ensure you hit the right margin as complexity increases.
I'm not interested in changing this rule.
--Dan
On Wed, May 17, 2023 at 3:23 PM Stuart Longland VK4MSL via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
A major part of my workflow is to either display two windows side-by-side with different but related files, or the same file "split vertically" to show two different parts of the same file side-by-side. This enables me to refer to one piece of code whilst working on the other.
This.
Martin. KD6YAM
-- Stuart Longland (aka Redhatter, VK4MSL)
Dan & Stuart (& Martin, below),
he argued that if your code was getting constrained to the right-hand edge (in his words "more than 3 levels of indentation"), your functions were probably getting too complex
OK, I get that. I follow the rule of refactoring down to "single-purpose" functions all the time. But, here's an example of a function that can't get any simpler: It's only doing one thing (repeatedly 9 times). It should only take (9 + overhead) lines of code, but with PEP8 it gets spread out to 50 lines.
definterpret_extra_channel_data(self, mem, _mem): mem.extra =RadioSettingGroup("Extra","extra") mem.extra.extend( [ RadioSetting( "rev","Reverse",RadioSettingValueBoolean(_mem.rev) ), RadioSetting( "compander", "Compander", RadioSettingValueBoolean(_mem.compander), ), RadioSetting( "talkaround", "Talkaround", RadioSettingValueBoolean(_mem.talkaround), ), RadioSetting( "pttid", "PTT ID", RadioSettingValueList( self._PTT_IDS,self._PTT_IDS[_mem.pttid] ), ), RadioSetting( "bclo", "Busy Channel Lockout", RadioSettingValueList(self._BCLO,self._BCLO[_mem.bclo]), ), RadioSetting( "optsig", "Optional Signaling", RadioSettingValueList( self._OPT_SIGS,self._OPT_SIGS[_mem.optsig] ), ), RadioSetting( "dtmfSlotNum", "DTMF", RadioSettingValueList( self._DTMF_SLOTS,self._DTMF_SLOTS[_mem.dtmfSlotNum] ), ), RadioSetting( "twotone", "2-Tone", RadioSettingValueList( self._TONE2_SLOTS,self._TONE2_SLOTS[_mem.twotone] ), ), RadioSetting( "fivetone", "5-Tone", RadioSettingValueList( self._TONE5_SLOTS,self._TONE5_SLOTS[_mem.fivetone] ), ), ] )
vs. this version with a 132 char line limit:
definterpret_extra_channel_data(self, mem, _mem): mem.extra =RadioSettingGroup("Extra","extra") mem.extra.extend( [ RadioSetting("rev","Reverse",RadioSettingValueBoolean(_mem.rev)), RadioSetting("compander","Compander",RadioSettingValueBoolean(_mem.compander)), RadioSetting("talkaround","Talkaround",RadioSettingValueBoolean(_mem.talkaround)), RadioSetting("pttid","PTT ID",RadioSettingValueList(self._PTT_IDS,self._PTT_IDS[_mem.pttid])), RadioSetting("bclo","Busy Channel Lockout",RadioSettingValueList(self._BCLO,self._BCLO[_mem.bclo])), RadioSetting("optsig","Optional Signaling",RadioSettingValueList(self._OPT_SIGS,self._OPT_SIGS[_mem.optsig])), RadioSetting("dtmfSlotNum","DTMF",RadioSettingValueList(self._DTMF_SLOTS,self._DTMF_SLOTS[_mem.dtmfSlotNum])), RadioSetting("twotone","2-Tone",RadioSettingValueList(self._TONE2_SLOTS,self._TONE2_SLOTS[_mem.twotone])), RadioSetting("fivetone","5-Tone",RadioSettingValueList(self._TONE5_SLOTS,self._TONE5_SLOTS[_mem.fivetone])), ] )
That cuts it down to 15 lines. This is much, much easier to read. It only takes a split second to understand that "it's just a block of settings." The 50-line version takes way longer to inspect before you can see that there's nothing special about any of the 9 settings.
Martin and Stuart,
side-by-side viewing
I would also argue that even then, it's more important to preserve vertical real estate than horizontal. When all you can see within 50 physical lines is 9 logical lines of code, you easily lose track of where you are in the grand scheme of things. Sticking to this one simple example, say that someone added six more RadioSetting calls to this function and moved the Compander setting to the bottom because it logically goes together with one of the new settings. With one line per call, you'd spot the difference immediately in a side-by-side. With 15 calls spread across 80 lines, you wouldn't.
I'm just say'n, it's been 50 years since the world went from 80-character teletypes to 132-character line printers and I, for one, never looked back.
Anyway, If you can't see your way to 132 much less 160, I'll take whatever I can get. Do I hear 100? Hell, I'd even take 90. I lost count of how many comments I've written in the last few days that had to be continued to the next line because of just one word.
(Dan, I saw your "not interested" declaration. Please know that I'm not in the habit of beating a dead horse, so this will be my last post on the subject, and I'll certainly respect your final decision. I'll get back to work now. Thanks for listening.)
On 5/17/2023 5:16 PM, Craig Jones via chirp_devel wrote:
this will be my last post on the subject
Sorry, I lied. Just one more thing: Here is why the Black formatter chose to set their default line length to 88: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.ht...
participants (4)
-
Craig Jones -
Dan Smith -
Martin Cooper -
Stuart Longland VK4MSL