[dead]
Formatting a 25M-line codebase overnight
61–70 of 115 posts
Re: Formatting a 25M-line codebase overnight
#62I'm surprised they went with a all-at-once reformat. Even when doing it over a weekend this is bound to mess with a lot of open PRs at their scale. I had to introduce a formatter in a few sizeable codebases in the past (few 100k to few million LOC), and I always did it incrementally via a script that reformatted all files that are not touched in any open PR. The initial run reformatted 95% of all files. Then I ran th…
It's probably because the author can shit on others (let me guess, a senior principal something engineer).
Re: Formatting a 25M-line codebase overnight
#63How did I know this was going to be a rewrite in Rust?
Re: Formatting a 25M-line codebase overnight
#64What is even the point of formatting code anymore.
Re: Formatting a 25M-line codebase overnight
#65Earlier quoted context omitted.
That sounds even more insane to me, but I guess most of that code does not really touch financial transactions, otherwise it would be a nightmare being responsible to verify that.
Ruby code touches financial transactions. Card payments were migrated to Java when I left in 2022. Non-card payments (e.g., ACH, checks, various wallets) were still processed by Ruby. PCI-related/vaulting code lived in its own locked-down repo. I think that was a mix of Go and Ruby. Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations,…
> Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations, however, took a lot to build and evolve.
Pretty much. I've worked at places with PHP payment processing that worked just fine, and at a place with C++ payment processing (and no testers) and it worked just fine. I wasn't around when the systems were first built though so not sure if there were tears along the way.
Re: Formatting a 25M-line codebase overnight
#66I don't understand why the felt the need to do a big-bang merge like this. Its a formatter, so the files should be functionally equivalent before and after. Why not just enable it for new files/edit files for a while, then once comfortable apply it to old files in batches? What advantage does the big bang merge give? Seems higher risk for the same reward
Re: Formatting a 25M-line codebase overnight
#67Earlier quoted context omitted.
^^^^^^^^^^^^^^^^^^^ I recently wrote a very esoteric Python script. 100 lines of code. No classes, no functions, but yes argparse. I've tried out the latest open source models on the task. They go bananas. It's like Enterprise fizzbuzz ( https://github.com/enterprisequalitycoding/fizzbuzzenterpris... ). They love classes and imports and reinventing the wheel. A great way for me to tell trash AI slop code is it'll def…
The bad part of LLM is it got trained on bad examples because us humans also don't know WTF we're doing.
Yeah maybe I need to do the old "you are a veteran engineer" nonsense. I've had some success telling it to implement everything it suggests and be production ready. I hate when it takes a shortcut and says I'll have to change it. That's kinda the whole point of me not writing the code...
Re: Formatting a 25M-line codebase overnight
#68I'm surprised they went with a all-at-once reformat. Even when doing it over a weekend this is bound to mess with a lot of open PRs at their scale. I had to introduce a formatter in a few sizeable codebases in the past (few 100k to few million LOC), and I always did it incrementally via a script that reformatted all files that are not touched in any open PR. The initial run reformatted 95% of all files. Then I ran th…
> I'm surprised they went with a all-at-once reformat. Even when doing it over a weekend this is bound to mess with a lot of open PRs at their scale.
Rebasing PRs should be trivial, just rewrite all commits reformatting the files it touches, then rebase, `git checkout --theirs`, run formatter again, and `git rebase --continue`. It's methodical and scriptable, you don't need to manually resolve any conflicts.
Re: Formatting a 25M-line codebase overnight
#69Man must me nice to have the time to put so much work into tabs.
Clean indenting is about saving time so you don't spend way too long getting lost trying to understand what seems like an insane piece of code until you realize it was a mundane bug hidden by incoherent indentation.
Re: Formatting a 25M-line codebase overnight
#70I don't understand why the felt the need to do a big-bang merge like this. Its a formatter, so the files should be functionally equivalent before and after. Why not just enable it for new files/edit files for a while, then once comfortable apply it to old files in batches? What advantage does the big bang merge give? Seems higher risk for the same reward
could introduce subtle bugs, so doing it all at once while it's on the front of everybody's mind with as much comprehensive review and testing of parts or the whole to everybody's satisfaction. if you don't do it all at once, you'd need to repeat the same amount of testing multiple times.
>files should be functionally equivalent before and after
when you say something like this, the road you are on is paved with good intentions.