Live data from Hacker News

Reformatting 100k Files at Google in 2011

laurent.le-brun.eu

91–100 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#91
post #50
post #40

Earlier quoted context omitted.

> It really is dumb to be arguing over tabs vs spaces, after all. In an in-house dialect of Haskell I used to work with, we solved this problem by just making tabs a syntax error. Never had any problems. (I think tabs might be have been allowed inside strings.)

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.

Re: Reformatting 100k Files at Google in 2011

#92
post #11
post #2

Autoformatting is so nice. Crazy to think that formatters only became popular after `gofmt`. I also found this related quote from Russ Cox intriguing: "Most people think that we format Go code with gofmt to make code look nicer or to end debates among team members about program layout. But the most important reason for gofmt is that if an algorithm defines how Go source code is formatted, then programs, like goimport…

The Perl world had perltidy (first release in 2002) many years before Go was even a thing. It's funny that Perl, a language notorious for it's "There's More Than One Way To Do It" (TMTOWTDI) philosophy had a tidier so early. Of course, perltidy is _ridiculously_ configurable. One thing I really love about gofmt is that it has no configuration at all. I think that was a major "innovation" and I'd love to see more lang…

There were also various Python formatters. The problem was the zeitgeist - engineers would tell me that "they didn't want an algorithm messing with their code" as though that was a serious concern, or that wading through endless pull-request changes for syntax was a good use of anyones time.

Re: Reformatting 100k Files at Google in 2011

#93
post #89
post #25

Earlier quoted context omitted.

At that point you could even use different languages. Maybe you like programs that look like Lisp and I don't. There was a project at Microsoft Research in the late 1990s/early 2000s that did exactly this - storing ASTs in source control instead of code - but the name escapes me at the moment.

Was it Intentional programming? I remember it being described as something similar to what you say, but the Wikipedia shows something slightly different. https://en.wikipedia.org/wiki/Intentional_programming

Quick 10 min into Googling, def. double check me:

You're right, ex. https://dev.to/jillesvangurp/comment/6gnb/

Sadly there's enough bitrot that ex. intentsoft.com is offline.

More here, but article is v opinionated/judgement oriented, comments are useful, but again, bitrot :( https://wiki.c2.com/?IntentionalProgramming

It strikes me that what I am describing as "bitrot" may also be "never really shipped, so the vagueness isn't accidental"

Re: Reformatting 100k Files at Google in 2011

#94
post #61

Earlier quoted context omitted.

A tool for updating bazel build target dependencies. It inspects build files and source code, then adds/removes dependencies from build targets as needed. It requires using global include paths in C/C++ sources. It is not perfect, but it is pretty nice!

If you're using Go with Bazel, gazelle is available outside Google: https://github.com/bazelbuild/bazel-gazelle Enabling tools like these was exactly the point of the enforced formatting. It worked extremely well.

I should add that it seems Gazelle is being expanded to other programming languages other than Go.

For example: https://github.com/Calsign/gazelle_rust

Re: Reformatting 100k Files at Google in 2011

#95
post #2

Autoformatting is so nice. Crazy to think that formatters only became popular after `gofmt`. I also found this related quote from Russ Cox intriguing: "Most people think that we format Go code with gofmt to make code look nicer or to end debates among team members about program layout. But the most important reason for gofmt is that if an algorithm defines how Go source code is formatted, then programs, like goimport…

Autoformatters got popular was because a lot people don't care about formatting, and those who do care can't win against the auto part of autoformatters. It works for go because gofmt was there from the start, so even if you are returning a multi-dimension array and elements come out unaligned, that's just accepted as how it is and nobody cares. For other languages, people will have to either accept "not caring" as b…

Interesting enough people still find things to argue about even with gofmt and goimports. The order of imports and maximum line length are two examples. I imagine if those were done by gofmt/goimports then people would argue about other things.

It's why we can't have nice things... Autoformatters do help though.

Re: Reformatting 100k Files at Google in 2011

#96
post #79

The real lesson here should be that source code shouldn't be stored in a text format, but in a well-defined strict binary format that stores the parse tree directly, which completely eliminates the need for formatters.

I agree with this sentiment. It also provides an opportunity to store other metadata with the code. It lets different people choose their formatting preference when rendering back to human readable code.

The source code is text thing seems like a "legacy" concept.

At the very least I think this is an interesting thing to explore. Maybe it leads nowhere...

Re: Reformatting 100k Files at Google in 2011

#97
post #71

Earlier quoted context omitted.

Make the one line change be a commit, then the reformatting be another one, review only the first one. It shouldn't be a problem with a proper review system.

All changes need to be reviewed. That's the point of code reviews. Your suggestion would allow people to bypass the code review by just saying "oh it's just cleanup don't worry".

My understanding is the 100k changes files were not reviewed by a human, they did some automatic validation, so that validation could also be done on demand, e.g. a commit saying "reformatted" could trigger a check to make sure the files were identical and bypass a human review... but sounds like they chose a reasonable approach.

I've always been against "reformat the whole code base" but it's an interesting example where it seems to have been the right choice.

Re: Reformatting 100k Files at Google in 2011

#98
The term "bikeshedding" comes up a lot on HN, when people spend a lot of time spinning wheels in endless debates about the things that are easy to debate while indefinitely deferring the tough conversations, but I think an underappreciated aspect of this meme is that the unimportant conversations quite frequently really are just that; unimportant, to everybody involved. Often (but not always) nobody actually cares. Caring is not necessarily represented by the amount of time or text spewed forth on a topic. A lot of things other than passion or importance factor into how much verbiage comes through and it is a mistake to overinterpret mere volume.

Unfortunately, the flip side of this coin is harder to deal with; sometimes truly important issues or things that people do deeply care about have disproportionately too little verbiage. Finding those can be very difficult.

Re: Reformatting 100k Files at Google in 2011

#99
post #11
post #2

Autoformatting is so nice. Crazy to think that formatters only became popular after `gofmt`. I also found this related quote from Russ Cox intriguing: "Most people think that we format Go code with gofmt to make code look nicer or to end debates among team members about program layout. But the most important reason for gofmt is that if an algorithm defines how Go source code is formatted, then programs, like goimport…

The Perl world had perltidy (first release in 2002) many years before Go was even a thing. It's funny that Perl, a language notorious for it's "There's More Than One Way To Do It" (TMTOWTDI) philosophy had a tidier so early. Of course, perltidy is _ridiculously_ configurable. One thing I really love about gofmt is that it has no configuration at all. I think that was a major "innovation" and I'd love to see more lang…

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.

Re: Reformatting 100k Files at Google in 2011

#100
post #99
post #11

Earlier quoted context omitted.

The Perl world had perltidy (first release in 2002) many years before Go was even a thing. It's funny that Perl, a language notorious for it's "There's More Than One Way To Do It" (TMTOWTDI) philosophy had a tidier so early. Of course, perltidy is _ridiculously_ configurable. One thing I really love about gofmt is that it has no configuration at all. I think that was a major "innovation" and I'd love to see more lang…

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!
Post reply on HN