Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formatting a 25M-line codebase overnight

stripe.dev

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Formatting a 25M-line codebase overnight

#101

Post by sgc »

throawayonthe wrote: post #93
sgc wrote: post #74

Earlier quoted context omitted.

Every LLM I have ever asked about this says they perform better when they receive pretty-printed code because it is easier to see structure and priorities. It has been an almost universal recommendation for me, and it makes sense since LLMs are just mimicking human expression.

you asked the llm? i'm confused you do understand it can't "know" how it performs right?

You actually think that LLMs are not fed docs on how they work in order to help users interact with them better? Asking an LLM how to use it is based on the reasonable presumption that the company making it will prioritize making it useful for users and work on programming it with its own best practices.

Again, it makes perfect sense as well based on how they are trained in the first place. Look at how they tokenize whitespace and you will see why it's useful. Each number of repeating white spaces gets a unique token (so 2 whitespaces = token1, 3 whitespaces = token2) - so it actually does make a very clear reinforcing hierarchy readily available. And we all know if there is anything an LLM needs, it is reinforcement of important points.

Re: Formatting a 25M-line codebase overnight

#102

Post by saghm »

kevin_thibedeau wrote: post #100
saghm wrote: post #89

Earlier quoted context omitted.

I've always thought it would make sense for formatters to be baked into the toolchain so that they can reuse the language's parser (presumably exposed as a library) and then be implemented via parsing to AST and then formatted back out so that they're guaranteed to be correct and normalized. This doesn't seem to be how most formatters work in practice though, although I'm not sure if it's because of performance reaso…

That is essentially what clang-format is.

Good point, I hadn't really thought about it, but the name makes it pretty clear it's using clang's tooling. I only have worked a small amount in C++ in my career years back ago, but I distinctly remember feeling like clang-format was essentially perfect from my perspective, so it's nice to know that my abstract ideals bear out in practice.

Re: Formatting a 25M-line codebase overnight

#104

Post by mistrial9 »

Terr_ wrote: post #45
CrzyLngPwd wrote: post #20

One of my first jobs was a small software company writing software for a small number of clients, in MS basic PDS. The lead developer didn't like to bother with formatting code, so I wrote a tool called makenice to format his nasty spaghetti gibberish into something with good indents and layout to make it easier for us normal people to parse. He was furious, literally spun in circles about it right in the office in f…

I find a lot of these conflicts I can't resolve when everybody agrees that the pain of ugly/unnecessary diffs is greater than the pain of minor formatting disagreements.

its because some people learned to put meaning into different ways to layout dense expressions, or different kinds of comments in difference contexts.

python was "weird" at first to C-tribe, because of the strict layout used to eliminate some of the syntax tokens. These stories come from a time before "order over all" in some factory code base was seen as Universally a virtue of some kind

Re: Formatting a 25M-line codebase overnight

#105

Post by munk-a »

e28eta wrote: post #80
munk-a wrote: post #32

Earlier quoted context omitted.

Outside of the naming - this is a perfectly sane thing to do for developer comfort and can usually be accomplished with simple transformations. There are often limitations (like manually added indentation/spacing for alignment) but as long as you're very intentional about what changes you'll allow and have a good understanding of the language it can be an extremely safe operation.

I think git’s naming is actually pretty reasonable: smudge (on checkout) & clean (on stage).

Oh smudge and clean are excellent names. My singly held objection to the OP was that they called one of the scripts "makenasty" instead of like "makemunkastyle" or something more neutral. I think it's an excellent idea I'd just avoid being judgemental in naming. You can consider my deep love of BSD braces super nasty but I'd prefer you didn't label it that way.

Re: Formatting a 25M-line codebase overnight

#106

Post by munificent »

Terr_ wrote: post #47
munificent wrote: post #29

> We chose a Saturday to format the entire codebase to avoid merge conflicts. And while our test suite gave us high confidence we'd gotten everything right, it's always a bit daunting to have a diff so large that GitHub can't render it. The dart formatter has an internal sanity check. It walks through the unformatted and formatted strings in parallel skipping any whitespace. If any non-whitespace characters don't mat…

I imagine a fancier version would be to compare the Abstract Syntax Trees.

The balancing act is that the fancier your sanity check, the greater the chance of something slipping through its cracks too. Walking too strings in parallel is very simple and hard to get wrong. Traversing an AST and skipping a branch is exactly the kind of easy-to-make bug that the sanity check is designed to catch.

What I'd like to do is something somewhere in the middle where I walk the token stream and check that every token of the input ended up in the output, but I haven't figured out a simple and fast way to do that yet. Performance is particularly tricky because I obviously don't want to burn a bunch of CPU cycles on a sanity check that exists only to catch bugs.

Re: Formatting a 25M-line codebase overnight

#107

Post by munificent »

saghm wrote: post #90
hyperhello wrote: post #77

Earlier quoted context omitted.

Strictly speaking that wouldn’t work, since a1 is different from a 1, for example.

I don't think they're trying to say that this is a sufficient test for correctness but a necessary one.

Correct. It won't catch 100% of possible bugs, but it will catch most.

The kind of bugs that are easiest to write in a formatter is dropping a bit of syntax on the floor and forgetting to include it in the output, and the sanity check will catch those.

It's also definitely possible to miss some whitespace that's necessary for things like identifier separation, but... it's a sanity check, not a proof of correctness.

Re: Formatting a 25M-line codebase overnight

#108

Post by munificent »

Skeime wrote: post #92
munificent wrote: post #29

> We chose a Saturday to format the entire codebase to avoid merge conflicts. And while our test suite gave us high confidence we'd gotten everything right, it's always a bit daunting to have a diff so large that GitHub can't render it. The dart formatter has an internal sanity check. It walks through the unformatted and formatted strings in parallel skipping any whitespace. If any non-whitespace characters don't mat…

Lots of formatters also unify things like trailing commas, so it would be slightly more involved than this.

Yes, the dart formatter does that now too. So the sanity check ignores commas and semicolons, which makes it less robust as a sanity check, unfortunately.

Re: Formatting a 25M-line codebase overnight

#110

Post by saghm »

munificent wrote: post #107
saghm wrote: post #90

Earlier quoted context omitted.

I don't think they're trying to say that this is a sufficient test for correctness but a necessary one.

Correct. It won't catch 100% of possible bugs, but it will catch most. The kind of bugs that are easiest to write in a formatter is dropping a bit of syntax on the floor and forgetting to include it in the output, and the sanity check will catch those. It's also definitely possible to miss some whitespace that's necessary for things like identifier separation, but... it's a sanity check, not a proof of correctness.

In practice, that's how most software testing works anyhow!
Post reply on HN