Live data from Hacker News

Reformatting 100k Files at Google in 2011

laurent.le-brun.eu

41–50 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#41
post #40
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.

> 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.)

So I'm guessing you mean Mu, the dialect by Standard Chartered.

Re: Reformatting 100k Files at Google in 2011

#42
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…

I mean you can do whatever you want in a hobby project you work on solo. I do want to say that I have the opposite view. People who use formatters want their code to be consistent and go the extra mile it ensure it does. It's like manual testing vs automated testing to me. Sure with manual testing you can test many more corner cases as they come up as an intelligent person is in the loop. But there will be mistakes m…

Im not sure how it's even remotely related to testing. I do agree that it depends on the person, just like every medium depends on both the artist creating the work and the patrons viewing it.

Many people who use formatters (myself included) just want consistent code and don't want to bicker with others about it. When it is soley owned by me and I'm doing it for fun, these reasons fall away for me.

Re: Reformatting 100k Files at Google in 2011

#43
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…

I think you're doing yourself a disservice by having to play with the formatting itself instead of being able to express what you mean with the tools the language already provides you. As soon as anyone else looks at your code or wants to participate in the development process, what is meaningful to you about the arrangement simply won't translate into their view; what is the use of a programming language if not to u…

I personally dislike ad-hoc DSLs that aren't composed of the language's existing syntax.

Considering I get pleasure from formatting the code beautifully I'm not sure how it's even possible to be doing _myself_ a disservice. It's like saying I'm doing a disservice learning guitar instead of listening to Coldplay on my speakers.

As far as others are concerned... I agree somewhat, but I don't think it's by any means proven. I think we are always better off then cobbled together code where formatting hasn't been thought about. By well-designed hand-crafted formatting can be expressive in it's own way IMO

Re: Reformatting 100k Files at Google in 2011

#44
post #32

I'd be curious what role "global approvers" at Google/Google's scale typically have/how many are there/what's the process?

I was at Google until a few years ago.

The purpose of global approvers was exactly things like this. If you want to do a mechanical change to an insanely huge number of files, they can potentially approve it.

In my experience, global approvers were used extremely rarely, only in cases like this where the transformation was purely mechanical and it was possible to verify that there were no logic changes.

Most of the time rather than global approvers, you were encouraged to use a system that would automatically split your change into a bunch of smaller CLs (PRs), automatically send those to owners of each module, then automatically merge the changes if approved. It would even nag owners daily to please review. If you had trouble getting approval for some files you could escalate to owners of a parent directory, but it'd rarely be necessary to go all the way up to global approvers.

Basically if there was even the slightest chance that your change could break something, it's always safer to ask individual code owners to approve the change.

Re: Reformatting 100k Files at Google in 2011

#45
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…

This. Automatically doing it well (clarifying the intent of the code) is an AI-complete problem. That's not an excuse for automatically doing it poorly and forcing everyone else to live with it.

Re: Reformatting 100k Files at Google in 2011

#46
post #23
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…

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.

Unison has something similar to what you're talking about: https://www.unison-lang.org/

Re: Reformatting 100k Files at Google in 2011

#47
post #42

Earlier quoted context omitted.

I mean you can do whatever you want in a hobby project you work on solo. I do want to say that I have the opposite view. People who use formatters want their code to be consistent and go the extra mile it ensure it does. It's like manual testing vs automated testing to me. Sure with manual testing you can test many more corner cases as they come up as an intelligent person is in the loop. But there will be mistakes m…

Im not sure how it's even remotely related to testing. I do agree that it depends on the person, just like every medium depends on both the artist creating the work and the patrons viewing it. Many people who use formatters (myself included) just want consistent code and don't want to bicker with others about it. When it is soley owned by me and I'm doing it for fun, these reasons fall away for me.

It meant to illustrate the same human weakness in consistency and repeatability disadvantages both manual testing and manual formatting. In essence manually formatting is a baker making every bread by hand. Some bread will be better then others. In contrast to an automated factory turning out the same quality bread every day.

Re: Reformatting 100k Files at Google in 2011

#48
post #42

Earlier quoted context omitted.

Im not sure how it's even remotely related to testing. I do agree that it depends on the person, just like every medium depends on both the artist creating the work and the patrons viewing it. Many people who use formatters (myself included) just want consistent code and don't want to bicker with others about it. When it is soley owned by me and I'm doing it for fun, these reasons fall away for me.

It meant to illustrate the same human weakness in consistency and repeatability disadvantages both manual testing and manual formatting. In essence manually formatting is a baker making every bread by hand. Some bread will be better then others. In contrast to an automated factory turning out the same quality bread every day.

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)

Re: Reformatting 100k Files at Google in 2011

#49
post #41
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.)

So I'm guessing you mean Mu, the dialect by Standard Chartered.

Yes, indeed. In it's circa 2014 incarnation, when I last worked there.

(I don't really know what happened to it since.)

Re: Reformatting 100k Files at Google in 2011

#50
post #40
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.

> 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 2024.

Post reply on HN