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

Reformatting 100k Files at Google in 2011

laurent.le-brun.eu

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#121

Post by stavros »

josephg wrote: post #118
autarch wrote: post #100

Earlier quoted context omitted.

Yes, that's why I love gofmt. There's nothing to debate!

I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff l…

These tools, like any tool of the type, bring your code to the 90th percentile. This is good for nine out of ten people, because it improves their code. It's also good for the tenth person, when he has to read the code of the other nine.

If you're the tenth person, and you work alone, or with other fastidious people, you won't like the formatter. That's fine, you don't need to use it.

Re: Reformatting 100k Files at Google in 2011

#122

Post by autarch »

josephg wrote: post #118
autarch wrote: post #100

Earlier quoted context omitted.

Yes, that's why I love gofmt. There's nothing to debate!

I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff l…

That's fine for your solo projects. It's definitely not okay at work.

Re: Reformatting 100k Files at Google in 2011

#123

Post by JyB »

josephg wrote: post #118
autarch wrote: post #100

Earlier quoted context omitted.

Yes, that's why I love gofmt. There's nothing to debate!

I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff l…

That’s for teams. No one care about an individual opinion.

Re: Reformatting 100k Files at Google in 2011

#124

Post by JyB »

icholy wrote: post #113
arp242 wrote: post #105

Earlier quoted context omitted.

Well-formatted code is more than just an AST. Even in Go, a language with probably one of the lowest style divergences out there (for better or worse) there are tons of style choices that aren't in an AST. Blank lines is an obvious one: where do you insert them to "group" sections of a 30 line function? Or are there no blank lines at all? Line length: just "wrap at columns X" (or never wrap) is not enough, because pe…

I prefer no blank lines. If you feel like you need one, write a line comment instead describing the next section.

I mean the whole Go stdlib barely use them right?

Re: Reformatting 100k Files at Google in 2011

#125

Post by JyB »

markrages wrote: post #27
vitiral wrote: post #7

I'm going to take a contrarian view here. Code formatting is amazing in a corporate environment where nobody truly cares about their code -- it's just a means to get a paycheck. It's also great for beginners to a language who are still trying to get a handle of the syntax. But where you are nearly the sole owner of a small library and you are crafting that library to be beautiful and understandable... there is someth…

Yes! Code is for people to read, not computers. Beautiful code uses the full expressiveness that the language allows.

And people have, by definition, a much easier time reading code when it’s always consistent across codebases. Thanks for making the point.

Re: Reformatting 100k Files at Google in 2011

#126

Post by tczMUFlmoNk »

neilv wrote: post #20
vitiral wrote: post #7

I'm going to take a contrarian view here. Code formatting is amazing in a corporate environment where nobody truly cares about their code -- it's just a means to get a paycheck. It's also great for beginners to a language who are still trying to get a handle of the syntax. But where you are nearly the sole owner of a small library and you are crafting that library to be beautiful and understandable... there is someth…

Also, sometimes the formatting simply makes reading something messy merely tractable, not aesthetically pleasing. Once, a product launch depended on me urgently kludging a device driver in Python (long story). And this involved a large hand-maintained mapping table. I wrote it quickly but carefully, and found some formatting that made the table readable enough, without implementing a minilanguage in Python. But the B…

Black supports ignoring sections with a `# fmt: off` directive, and a hand-formatted constant table is a common use for that:

https://black.readthedocs.io/en/stable/usage_and_configurati...

Other formatters have similar functionality; e.g.:

- /* prettier-ignore */: https://prettier.io/docs/en/ignore.html#javascript

- #[rustfmt::skip]: https://github.com/rust-lang/rustfmt?tab=readme-ov-file#tips

Re: Reformatting 100k Files at Google in 2011

#127

Post by josephg »

autarch wrote: post #122
josephg wrote: post #118

Earlier quoted context omitted.

I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff l…

That's fine for your solo projects. It's definitely not okay at work.

Why not? Whats the ROI of making the number of lines that separate functions the same across our entire codebase? That sounds completely pointless.

Re: Reformatting 100k Files at Google in 2011

#129

Post by autarch »

josephg wrote: post #127
autarch wrote: post #122

Earlier quoted context omitted.

That's fine for your solo projects. It's definitely not okay at work.

Why not? Whats the ROI of making the number of lines that separate functions the same across our entire codebase? That sounds completely pointless.

It's easier to read and refactor code when it's all formatted the same way. Otherwise diffs end up with tons of extraneous noise. Plus it adds needless decisions. If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it?

What about when someone leaves the company? Is it free game to reformat everything they wrote?

Why do you need to put your mark on code at work? It's not _your_ code. It belongs to the employer. The best work is work that is useful and not an irritant long after you're gone.

Re: Reformatting 100k Files at Google in 2011

#130

Post by morgante »

montag wrote: post #72
Arainach wrote: post #66

Earlier quoted context omitted.

Google doesn't use Git internally, and its code search and source control tools expose the concept of "show blame before this change", so in practice reformats like this aren't troublesome with regard to blame.

This is true but I think it would still be nice for VCS to have a first class concept of "peek through" changes (whitespace, formatting, etc.) for the purpose of blame.

It does. Just put ignored commits in a file: https://docs.github.com/en/repositories/working-with-files/u...
Post reply on HN