i'm going to full screen width

[Skaperen]

i've been told that a good reason to limit width of code, length of lines, to shorter than 80. such as 71, an old punch card limit used by the mainframe ForTran community, is to allow line by line comparison of code, side by side. over the past few years of coding in Python, with only a little in C or Pike, i have never used the side by side comparison. i have done code comparison, but i always do so by flipping back and forth between two work spaces. since each user is set up with ten work spaces, i can even do three way code comparison (not easy with side by side). i have decided that beginning year 2021 i will no longer try (i'm not always successful) to keep code narrow and will make use of my full width, which is 136 characters (174 for my tight terminal setup) of width.

i have my numeric keypad set to switch work spaces. i just press keypad 6 and of suddenly on work space 6. i have work spaces set up. numbered 0 to 9.

[Gribouillis]

Another good reason could be that other programmers reading your code may be annoyed by lines 136 characters long... Have you considered delegating this issue to an automated code beautifier such as black or yapf ?

[perfringo]

There is no multitasking in human brain and we have capacity of 7 ± 2 registers. It is high probability that after reading one 135 characters line we face register starvation and are unable to comprehend next line.

There is entertaining talk about this subject PyBay 2019: Raymond Hettinger: The Mental Game of Python. This is not about line lengths per se but cognitive overload which can be achieved with short lines as well (but with long lines quite certainly).

[Skaperen]

before i go read that article... how should variable name length be handled? i remember programming in a time when variable name length was limited to 6 characters (some early computers used 6 bit characters in a 36-bit register and Fortran adopted this in its first language specification)

[Skaperen]

Have you considered delegating this issue to an automated code beautifier such as black or yapf ?

not yet. the way i would want to do that is by keeping the original code as the edit base so that if i edit that code, i am working with what i originally put in there. of course this can have line number mismatches, making it difficult to find where dumped errors are. so, i will need to think about this. it depends on how well i like the reformatting. i see that black has a feature to make some sections not be reformatted. that can help on cases i do some special semantic formatting.

[Skaperen]

There is no multitasking in human brain and we have capacity of 7 ± 2 registers. It is high probability that after reading one 135 characters line we face register starvation and are unable to comprehend next line.

i think it is more a function of how much information on the line, reduced by how well the mind can link to what it already knows. a short line using only 2 character variable names can be harder for the mind to hold onto than the same code with variable name that present some genuine meaning, which will make the line longer by character count.

[perfringo]

i think it is more a function of how much information on the line, reduced by how well the mind can link to what it already knows. a short line using only 2 character variable names can be harder for the mind to hold onto than the same code with variable name that present some genuine meaning, which will make the line longer by character count.

These are separate subjects for me. How many variables and operations are on one line and comprehend what variable names mean.

As an example: line below contains only one totally readable variable (year) but chains together lot of built-in operators/functions so it's hard to understand what does it do:

sum([[[31, 30][i <= 6 and i % 2 == 0 or i > 7 and i % 2 != 0] if i / 2 != 1 else [28, 29][year % 4 == 0 and year % 100 != 0 or year % 400 == 0]] for i in range(1, 13)], [])

Result is list of integers representing days in months in given year. What one's registers do after reading this line ?

Naming is an art but I like this:

Namespaces are one honking great idea -- let's do more of those!

So instead match_of_comparison_first_occurance, match_of_comparison_second_occurance I would consider data structures (built-in or classes) and functions (namespaces).

[ndc85430]

In one of his talks (I forget which one), Kevlin Henney suggests that even 80 characters is too generous for line lengths. His argument is that people tend to read normally with shorter lengths anyway (think columns in a newspaper or journal article, for example). I've been writing lots of Clojure recently and have been trying to stick to around 50 characters per line. Can't say that I've noticed much yet, but that's probably because I've spent years of programming with longer lines!

[Skaperen]

50 character lines would end up with a lot more continuations to the next line or pressure to use shorter variable names. i do tend to write shorter lines. then there is the occasional long line (often comprehensions). it's not like i'm going to push all lines out to 136. but if one naturally goes out there, it is what it is.

my coding style is about what i find easy to read. but i am open to suggestions (to look and see how easy to read).