5 ms·
There is a strawman argument in the talk, about the limitation (or now, default) to 80 characters wide consoles which is presented as a "proof" that we're still
by fermigier 4y ago
There is a strawman argument in the talk, about the limitation (or now, default) to 80 characters wide consoles which is presented as a "proof" that we're still living in the past.
80 characters (plus or minus 10) has a justification outside the history of teletypes and VT100s: that's the optimum for readability.
Otherwise, there are good ideas, in the talk, but this particular one rubbed me in the wrong way.
- hoseja 4y agoOptimum for whom? Nineteenth century teletype operators? I never got that argument.
- goto11 4y agoOptimal for reading prose texts. I believe experiments have shown the optimal line width for reading speed and comprehension to be about 50-60 characters. But as far as I known this have only been researched for reading prose. I doubt the result will translate directly to reading source code, which is read in a completely different way.
- fermigier 4y agoYes, experiments are lacking for code, but I believe the physiological principles (eye fixation, etc) still stand. Also: the optimal line width for prose seems to be 50-75 characters (including whitespace). Source: https://baymard.com/blog/line-length-readability https://baymard.com/blog/line-length-readability Assuming you're using a language where indentation is either mandated (e.g. Python) or recommended (e.g. C with "One True Braces"), with 4-spaces indentation (here again, no experimental evidence, but this seems to be the norm nowadays), and you don't abuse cyclomatic complexity in your functions / methods, you have let's say between 2 and 4 indents on the left so 80 is close to the optimum. Note: up to 100 is probably still OK from a readability POW. But this assumes that all readers are able to increase their window size from the default 80. That's probably true for people using GUIs, but may still be problematic for people with sight issues (e.g. people over 50 or with more serious medical conditions...).
- jstimpfle 4y agos/POW/POV/
- lcnPylGDnU4H9OF 4y agoReminiscent of tabs vs. spaces, this seems to be a new battle in an old war and readability is (allegedly) being held captive by both sides.
- lou1306 4y agoIt's related to how reading and the human eye work. For each eye fixation, you take in about 5-10 characters. The optimal line length for books is about 60-75 characters, which takes somewhere between 6-15 fixation to scan. Code is not like books: most lines will be shorter than the "limit", there's indentation, you're typically reading monospaced characters on a screen, and you have syntax highlighting, etc. So, bumping the length up to 80 characters is still okay, as is the occasional outlier. But regularly writing 100-120 characters-long LoCs will definitely impact readability.
- jwdunne 4y agoYes, I find it harder to read code at lengths much longer than this. 120 is quite difficult. It also makes it even harder to read if you split the screen vertically, which I do all the time. That said, I don’t think it should be a hard limit and it’s fine if a lines a bit over, +/- 10 like you said. Certainly not something that we should contort into multiple lines just to keep under a hard limit. Unfortunately, a few auto formatters only do hard limits - it’d be interesting to see how an acceptable interval around the limit would work. Plus, I’ve noticed the limit makes more of a difference for comments than code so I try to keep comments under that. The written word appears more sensitive to line length.
- bruce343434 4y agoHow do you envision an interval around a limit? The fact is that you have to draw the line somewhere. If your interval is +-20, then setting a "limit" of 80 is really just a hard limit of 100.
- alpaca128 4y agoBy letting the code formatter exceed the limit if it allows for more readable formatting in certain cases. Going for a 100% hard limit means sometimes it'll shuffle chunks of code around because of 1-2 characters and that just doesn't make a lot of sense. Or in other words, by formatting the code more like a human than dumping the source tree with a blind set of rules. If Copilot is possible then so is an AI model able to consider how code actually looks on the screen.
- bruce343434 4y agoHow do you quantify the tipping point where a longer but continuous line is prettier than a broken line? (broken where?)
- atq2119 4y agoThey already answered the question: you use statistical methods (aka AI).
- faeriechangling 4y agoIn a book, line breaks don't necessarily have any meaning. In poetry they might, but in a book they probably don't. In programming, line breaks OFTEN have a meaning. Breaking up a sentence over multiple lines can TOTALLY change how it's interpreted by the computer. Using methods to circumvent this which allow you to have a computer interpret two lines as if it's a single line can confuse and change how it's interpreted by the programmer, at least momentarily. Refactoring your code to ensure it never exceeds 80 characters can ALSO make code harder to read, especially in modern languages that tend to be more verbose than what was seen in the TTY days. Expanding the limit to even 120 characters and aiming the average line to be significantly shorter allows you to have a more consistent readable style across languages where you aren't doing nearly as much weird crap to force source code to fit an arbitrary character limit. You STILL have to do quite a bit of rewriting to force code to fit 120 characters, but this may be worth the readability tradeoff.
- hrbf 4y agoThis is an argument I’ve heard over and over again throughout my coding career, especially from JavaScript and PHP developers. Interestingly enough there was a noticable overlap between this mindset and “clever” code, comprised of endless chaining, nested statements and/or internal recursion. They also never wrote code comments – at all. The defense being: “I think this way and its easier for me!” Regarding comments: “The code IS the documentation!” Of course, they were never around 6 months later to prove if they still understood their gobbledygook then. They never had to refactor anything. I have very rarely encountered a piece of code that would be hard to fit into 80 characters width while being readable. In fact, if done correctly, it forces you to break stuff up into manageable pieces and simple statements, to be explicit and often verbose. But if this runs counter to a messy, ego-centric style a developer is used to and there’s no one to reign them in, it’s what you get.
- lupire 4y agoThat's a bizarre statement, because chaining leads to shorter lines because each call can gets its own line and there are fewer assignments.