4 ms·
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.
by yencabulator 1y ago
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).
That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d31084e9d1118b25fd16580d9d8c2924b5740dff https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.
- azinman2 1y agoExcept this was new code.
- yencabulator 1y agoGenerally, large C projects have their own style that is followed whether the code is new or not.
- azinman2 1y agoAnd thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.
- yencabulator 1y agoLarge stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle. Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it. The only real way forward is full migration away from C, for which a better scope is a separate project.