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.
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.
That being said, as unlikely that scenario is, having it all in 1 line does not work either. The problem is that its very likely/possible that the true argument will be passed in in the form of a variable. So you’re back to needing something that is more code aware anyways.
This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, if someone is splitting code by inserting unnatural breaks then they are trying too hard, OR there could be various other legitimate reasons like very long function names and naturally verbose PL syntax that make even longer line widths unreasonable. Regardless of width constraints many people will split the arguments of extremely long function signatures onto multiple lines out of preference anyway, then grep will still get stuck without more caring regex.
These arguments always emerge out of someone misinterpreting guides as absolutes. No one is arguing we need to stick to 80 column terminals otherwise everyone would autowrap their commits and we'd have horribly unreadable breaks everywhere. 80 is historical, but trying to keep code width short does improve legibility, 80 just turned out to be a pretty good human standard as well.
The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. The tools in question, I presume to be a linter or formatter, complained noisily about line length prior to the adoption of this change.
It's not about someone misinterpreting guides as absolutes. It's very much about absolutes, in this case, that serve as guides.
Then it is about absolutes, the rule is absolute, but 80 width is a guide... being used as a rule.
I'm surprised the first to challenge the rule is about grepability and not how detrimental it is to legibility to use this as a hard rule.
perl -pe 's/\\\n//g'
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, \
bar, \
false)
print("Hello, world")
flag = \
true
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, bar, false)
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 line-oriented (same for sed, etc). Sure, it's possible to make the output have context, but to actually do a multi-line grep correctly is much more complex.
I think that's the sort of grep usage linus was referring to.
> So I dunno, still prefer 80-88 characters for coding, 100 max.
I also prefer most lines to be under 80 characters, but for the sake of keeping a function call on one line, or keeping important things together, I'm fine with exceptions.
Some code splits onto multiple lines naturally (like moving a function call in a function's arguments into its own temporary variable). Other times, it becomes less readable as several shorter lines.
Thus I don't think a hard rule of 80 is good, simply a general philosophy that readable code is good and that's more important than line length.