[chirp_devel] Is FLAKE8 line length 80 still appropriate?

[Stuart Longland VK4MSL]

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/Documentation/CodingStyle?h=v3.19#n29

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,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.