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

111–120 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#111

Post by repsilat »

aiuto wrote: post #110

I want to start by saying that I do not want to diminish or disparage the work that Russ, Rob, Laurent, and others have done. It has made the Google code base better. That is an inarguable fact. Nor do I want to pick on buildifier or gofmt or any other tool as a singleton problem. I'll talk about buildifier because that is what I personally fight with. Others may have different demons. (YDMV - "your daemon may vary".…

For this sort of change I think the best strategy is "two passes".

Auto-format those O(30k) files and get global approval. Then, separately, make your two-line semantic change and seek approval from local owners.

Re: Reformatting 100k Files at Google in 2011

#112

Post by vitiral »

thfuran wrote: post #109
vitiral wrote: post #48

Earlier quoted context omitted.

Ah, makes sense. I think there are use-cases for both, even personal hobby projects. There's some languages with so much damn syntax that I don't think I could even begin to write code without a formatter (I'm looking at you rust and Java) and others where it stays out of your way (python, Lua, etc)

A language with semantic white space seems a somewhat strange choice for an example of when formatting stays out of your way.

Fair enough! I only wrote it early in my career, it might feel more restrictive now

Re: Reformatting 100k Files at Google in 2011

#113

Post by icholy »

arp242 wrote: post #105
afavour wrote: post #23

Earlier quoted context omitted.

I’ve wondered before whether the world would be well served by a programming language (or source control system, I suppose) that just stores ASTs in files rather than text code. When users open the file the editor formats to whatever their personal preference is, then saves edits back to the AST. It really is dumb to be arguing over tabs vs spaces, after all.

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.

Re: Reformatting 100k Files at Google in 2011

#114

Post by arp242 »

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.

Well okay, but a great many people disagree and this sort of thing isn't captured in an AST, so clearly it's not a suitable format for storing code.

Re: Reformatting 100k Files at Google in 2011

#115

Post by aiuto »

repsilat wrote: post #111
aiuto wrote: post #110

I want to start by saying that I do not want to diminish or disparage the work that Russ, Rob, Laurent, and others have done. It has made the Google code base better. That is an inarguable fact. Nor do I want to pick on buildifier or gofmt or any other tool as a singleton problem. I'll talk about buildifier because that is what I personally fight with. Others may have different demons. (YDMV - "your daemon may vary".…

For this sort of change I think the best strategy is "two passes". Auto-format those O(30k) files and get global approval. Then, separately, make your two-line semantic change and seek approval from local owners.

That is missing the point about the misdirection of costs. Your suggestion forces the people doing meaningful semantic changes, into involuntary servants to the goal of cleaning the stylistic problems. It's fine to have a policy that costs a little to each of the owners of their own code. It's a tax for the overall good. It becomes a problem if the cost of compliance is shifted to "the next person who looks at it." That encourages people to not look at it.

Re: Reformatting 100k Files at Google in 2011

#116

Post by ukuina »

refulgentis wrote: post #91
afavour wrote: post #50

Earlier quoted context omitted.

Arguably it would be a problem for a coworker that wanted to use tabs. “We’ll just force everyone to do things one way” kind of ignores the point I was making. It shouldn’t be necessary for you to care how anyone else formats their code, same as you don’t care what font their code displays in or what text editor they use. It feels like a vestigial aspect of programming that we have to concern ourselves with it in 202…

100%, way this felt in practice at Google was I could have whatever I wanted in my IDE, and it'd be transformed upon check-in into the house style, which I don't need to care about FWIW, just happy to have a chance to unload this thought finally: it had surprisingly little impact on code reviews, in that the "personal preference I need to enforce" just ascended abstraction levels.

Does the IDE transform the existing code in the repo back into your preferred style on the next checkout?

Re: Reformatting 100k Files at Google in 2011

#117

Post by MBlume »

aiuto wrote: post #110

I want to start by saying that I do not want to diminish or disparage the work that Russ, Rob, Laurent, and others have done. It has made the Google code base better. That is an inarguable fact. Nor do I want to pick on buildifier or gofmt or any other tool as a singleton problem. I'll talk about buildifier because that is what I personally fight with. Others may have different demons. (YDMV - "your daemon may vary".…

Seems like the solution here is to set up buildifier so that it can send out robot CLs on an ongoing basis.

Re: Reformatting 100k Files at Google in 2011

#118

Post by josephg »

autarch wrote: post #100
ravishi wrote: post #99

Earlier quoted context omitted.

The thing about configurable vs non-configurable in this case is that when its configurable then people will spend time debating how exactly they should configure it.

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 like that.

By removing the maker’s marks, these tools make my code less readable. While, in my opinion, adding practically no value. I’m more than happy for every line of code to have consistent indentation (of course, but it did already). I also don't have a problem with silly but arbitrary formatting choices - like sorting my import lines. But these tools seem to drive so far for consistency that it costs readability.

That’s a nope for me. No debate.

Re: Reformatting 100k Files at Google in 2011

#119

Post by josephg »

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 think that's a terrible choice. Its like saying "I don't like whitespace in webpage design. If they need whitespace, fill it with content - like maybe some text."

Whitespace gives readers subtle information about the structure of a function before they read any of it. Its a powerful tool. Dismissing or - worse - deleting whitespace wholesale sounds profoundly misguided to me.

Why make code harder to read? Where's the benefit to your approach? I can't see any.

Re: Reformatting 100k Files at Google in 2011

#120

Post by dartos »

jrockway wrote: post #101
singron wrote: post #88

Earlier quoted context omitted.

From my memory, extremely large but semantically simple changes still used global approvers since it wasn't considered worth the effort to get approval from hundreds or thousands of individual OWNERs using rosie. Also, with a change of this magnitude, especially one affecting BUILD files, it might not have been possible to create the mega-CL that rosie uses, but I don't remember specific limitations on that.

That's exactly what I remember. I did a few LSCs; one I used Rosie just to see how it worked (I recall wanting to use it for all my CLs because it submits after someone clicks approve and the tests pass), but most of the time it was easier to find a global approver and submit the whole thing atomically.

I always appreciate these googler threads talking about all the Google internal tools.

Reminds me of all the impenetrable jargon around me when I was new

Post reply on HN