5 ms·

Code style can be pretty damn gnarly to automate. Not sure if it's still the case, but the Linux kernel used to have a script checkpatch.pl that was a few thou

Code style can be pretty damn gnarly to automate. Not sure if it's still the case, but the Linux kernel used to have a script checkpatch.pl that was a few thousand lines of Perl, dense with regex, to check that patches conform to kernel style guidelines. And those guidelines are basically just K&R C style. When I was a teenager I really wanted to get into contributing to the kernel, so I did this babby's first patch, fixing the code style for this rather large, extremely messy 3rd party driver in the tree. Must have taken me a couple days; hardly any single line conformed to the guidelines. Sent the patch in and Greg KH replied saying thanks and all, but we were planning on just deleting this driver anyway, so no merge. Somewhat embarassing intro to open source contribution :D

chrisan 4y ago
Did you mean code style automation back then? Today's code style automation seems pretty solid.
- mtlmtlmtlmtl 4y ago
  No idea what they do in the kernel now, but back then there was no automation, just that giant perl script that told you all the places where the style diverged from guidelines.
  - MrJohz 4y ago
    I don't know about the Linux codebase either, but a lot of languages these days tend to have an CST-based formatter - given a syntactically correct but arbitrarily formatted file, it will essentially rewrite it into a standardised form. There's a lot of cleverness going on on top of that - using the context of the code to format things in different ways - but the core idea is generally to parse the code and then format that, rather than apply purely text-based rules. The benefit of this is that it almost cannot go wrong (unlike older formatters which might stumble over a line of code and accidentally write invalid or incorrect code). The disadvantage is that there are usually fewer configuration options, so if you don't like the formatting, you might just be stuck with it anyway.
    - mtlmtlmtlmtl 4y ago
      Yeah, rustfmt, gofmt etc is wonderful. Definitely been a lot of progress on this lately, with more modern languages anyway.
yencabulator 4y ago
Meanwhile, Go has essentially solved the problem, and Rust copied the idea. Neither of those languages need to bother humans with the details of exact code layout. The post-C world is a lot better.

chrisan 4y ago

Did you mean code style automation back then? Today's code style automation seems pretty solid.

mtlmtlmtlmtl 4y ago
No idea what they do in the kernel now, but back then there was no automation, just that giant perl script that told you all the places where the style diverged from guidelines.
- MrJohz 4y ago
  I don't know about the Linux codebase either, but a lot of languages these days tend to have an CST-based formatter - given a syntactically correct but arbitrarily formatted file, it will essentially rewrite it into a standardised form. There's a lot of cleverness going on on top of that - using the context of the code to format things in different ways - but the core idea is generally to parse the code and then format that, rather than apply purely text-based rules. The benefit of this is that it almost cannot go wrong (unlike older formatters which might stumble over a line of code and accidentally write invalid or incorrect code). The disadvantage is that there are usually fewer configuration options, so if you don't like the formatting, you might just be stuck with it anyway.
  - mtlmtlmtlmtl 4y ago
    Yeah, rustfmt, gofmt etc is wonderful. Definitely been a lot of progress on this lately, with more modern languages anyway.

yencabulator 4y ago

Meanwhile, Go has essentially solved the problem, and Rust copied the idea. Neither of those languages need to bother humans with the details of exact code layout. The post-C world is a lot better.