81–90 of 330 posts
This!! At people are insisting we use a max of 80 columns for the linter. It's a huge pain compared to 100 or 130 columns and doesn't help readability. Everytime someone tries to argue for it I want to suggest we swap their Mac for a Commodore 64...
80 columns on a C64 is a real reach. You need special hardware (or horribly slow & fuzzy text) for that.
The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…
Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is…
Often you combine this with a line oriented but overly false-positive prone query, like a file-level grep for `foo`, since the AST parsing is slower. Then you reprocess with AST-based tools.
There's some fairly ergonomic tooling for this kind of transformation, although often you need a tool per language, which is annoying.
Earlier quoted context omitted.
Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is…
Well the real answer is that we shouldn't treat code as "line oriented". It's a tree. Use a tool meant for tree processing, like clang-format or the various similar tools for other languages. These let you query the AST or CST of the language, which is very useful. Often you combine this with a line oriented but overly false-positive prone query, like a file-level grep for `foo`, since the AST parsing is slower. Then…
The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…
Earlier quoted context omitted.
I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.
A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)
Earlier quoted context omitted.
Well, the C64 had a 40 column display width for the BASIC interpreter, but I think it was possible to have statements that wrapped and could go up to 80 characters (I may be wrong about that though).
The more you know! Thanks.
The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…
Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is…
For example for a function foo, it's needlessly hard to grep for its declaration, imports and calls independently. Looking for one will probably surface the others.
I agree that 80 is too small in 2020, and hasn't been since around 80x25=2000, but LLVM is stuck at 80 columns [1]. I'd be interested to see a canvas of other big projects. [1] https://llvm.org/docs/CodingStandards.html#source-code-width
I've never measured it, and my observation is very likely biased (as I've mostly worked with C++), but I've found 80 columns in big C++ projects often very limiting. Maybe less often now, after people are most accepting to new features; e.g type inference `auto` over `MyNameSpace::BlahContainer::const_iterator iter`.
Earlier quoted context omitted.
The #3 productivity app on the Mac App Store is a $2 app that enables this on Apples: https://apps.apple.com/us/app/magnet/id441258766?mt=12
I'll have to try this.