6 ms·

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 wo

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 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.

joshuamorton 6y ago
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 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.
- saagarjha 6y ago
  Unfortunately, this now means that your code searching tool must have knowledge of the language you are running it on. Generally, since you want one tool, that means it needs to either support them all or be designed like LSP…
  - _ZeD_ 6y ago
    Or... You can use and ide for this... (Eclipse have generic text and specific programming search for that)
williamdclt 6y ago
I do this sort of grepping regularly, and would love a more code-oriented tool. Ignore whitespace, integrate syntax notions... 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.
tomxor 6y ago
> where 'true' is split onto a newline, that naive grep misses it. 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.
- deleted 6y ago
  [deleted]
- zapzupnz 6y ago
  > This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, 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.
  - tomxor 6y ago
    > The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. 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.
addicted 6y ago
I have a fairly simple solution for the scenario you’ve presented. grep, and return some context (maybe +5) and then grep on that again with the argument you’re looking for (give a negative context this time so you get the entire function call) 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.
moonchild 6y ago
Then pipe through perl -pe 's/\\\n//g' Before grepping
- wool_gather 6y ago
  Turning the entire file into a single line really doesn't seem like a solution. Now foo(1, bar, false) print("Hello, world") flag = true shows up in your grep output, and not in a particularly helpful rendering.
  - moonchild 6y ago
    No? That just merges continuation lines. So if your original file is foo(1, \ bar, \ false) print("Hello, world") flag = \ true Then the postprocessed output is: foo(1, bar, false) print("Hello, world") flag = true And your grep output is just foo(1, bar, false)
    - wool_gather 6y ago
      Sorry, what language are we talking about that has escaped line continuations for expressions like that?
      - moonchild 6y ago
        C

joshuamorton 6y ago

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 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.

saagarjha 6y ago
Unfortunately, this now means that your code searching tool must have knowledge of the language you are running it on. Generally, since you want one tool, that means it needs to either support them all or be designed like LSP…
- _ZeD_ 6y ago
  Or... You can use and ide for this... (Eclipse have generic text and specific programming search for that)

williamdclt 6y ago

I do this sort of grepping regularly, and would love a more code-oriented tool. Ignore whitespace, integrate syntax notions... 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.

tomxor 6y ago

> where 'true' is split onto a newline, that naive grep misses it. 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.

deleted 6y ago
[deleted]
zapzupnz 6y ago
> This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, 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.
- tomxor 6y ago
  > The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. 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.

addicted 6y ago

I have a fairly simple solution for the scenario you’ve presented. grep, and return some context (maybe +5) and then grep on that again with the argument you’re looking for (give a negative context this time so you get the entire function call) 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.

moonchild 6y ago

Then pipe through perl -pe 's/\\\n//g' Before grepping

wool_gather 6y ago
Turning the entire file into a single line really doesn't seem like a solution. Now foo(1, bar, false) print("Hello, world") flag = true shows up in your grep output, and not in a particularly helpful rendering.
- moonchild 6y ago
  No? That just merges continuation lines. So if your original file is foo(1, \ bar, \ false) print("Hello, world") flag = \ true Then the postprocessed output is: foo(1, bar, false) print("Hello, world") flag = true And your grep output is just foo(1, bar, false)
  - wool_gather 6y ago
    Sorry, what language are we talking about that has escaped line continuations for expressions like that?
    - moonchild 6y ago
      C