[gostsamo]

If I only need to read some text or code, the line length does not matter, because the sound from the screen reader is linear by nature. There is something to be said about natural breaks on statements and the like, but we assume that we are talking about expressions which just happen to be long.

If I need to edit though, I need to navigate to the section in question. My options are to use word by word navigation either from the line start or word by word from the line end (I have short keys for those). If the line is too long, word by word might take quite the number of keystrokes to reach the target position. ctrl+f might be faster. Some vim magic might be useful for such cases, but it would be an overkill.

Separately, there could be some attention fatigue if I need to here only the end of the line, but it is long and my mind wanders while waiting for the interesting bits. This is a corner case though.

[yeukhon]

Thank you! Would you mind me asking whether you use any IDE like VS Code, IntelliJ etc?

I think, it would be ideal if the read and edit are fit for your need (say 80 characters max) inside the editor, but when you are committing, there is a pre-commit hook that would automatically reformat (but your IDE can still display and edit as if it was at 80 max characters).

Now sure how practical that is (and I imagine that isn't really a thing today), but what is your take on that?

[gostsamo]

I'm using vs code for python development and the company has standardized on black with pre-commit hooks. I'm actually happy with the setup. Line length is not important for me, so short lines work too as they work for everyone else.