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

131–140 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#131

Post by throwaway2037 »

refulgentis wrote: post #93
whstl wrote: post #89

Earlier quoted context omitted.

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 vague…

Hat tip for c2.com link! The follow-up is savage: https://wiki.c2.com/?CritiqueOfIntentionalProgramming

Re: Reformatting 100k Files at Google in 2011

#132

Post by dmurray »

jrockway wrote: post #102
autarch wrote: post #100

Earlier quoted context omitted.

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

Helpfully, you can debate between "gofmt", "gofmt -s" and "gofumpt". I actually like how gofumpt formats stuff but ... nobody else on the team would have it, so it would make things worse.

You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing.

I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple tools to collaborate on code.

Re: Reformatting 100k Files at Google in 2011

#133

Post by rurban »

autarch wrote: post #11
wonger_ wrote: 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…

I now almost always format C and C++ with clang-format -I pure, without any .clang-format overrides.

There's no need for lengthy discussions with co-workers then. Just for bigger projects there's a need for Statement Macro Declarations, but that's arguably a bug/limitation in clang-format

Re: Reformatting 100k Files at Google in 2011

#134

Post by spc476 »

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".…

> formatting rules without firm, incredibly strict enforcement ends up being a tax on the janitors

Wait! I thought Google only promoted and rewarded people who do new development, not maintenance. What gives?

Re: Reformatting 100k Files at Google in 2011

#135

Post by fragmede »

jerf wrote: post #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. C…

> Caring is not necessarily represented by the amount of time or text spewed forth on a topic.

The meta says that it is. there are only 81600 seconds most days, and you get to choose them how you want, so choose how you spend them wisely. if that's arguing over tabs or spaces, then that's your choice.

Re: Reformatting 100k Files at Google in 2011

#136

Post by fragmede »

paulddraper wrote: post #60
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…

I don't find the mental burden of formatting code to have a positive ROI. I want to write syntacially-valid code, without worrying about the visual presentation of it. (I want a good presentation, but I don't want to put forth the effort to create it.)

Yeah that's why I fight with how I feel about python so much. In other languages I can just shove the curly bracket in the right place and fix the whitespace later, but Python has whitespace as significant, so I'm forced to fix it/get it right. But that means it's right when I dig a "temporary" script up years later.

Re: Reformatting 100k Files at Google in 2011

#137

Post by cmcaine »

dmurray wrote: post #132
jrockway wrote: post #102

Earlier quoted context omitted.

Helpfully, you can debate between "gofmt", "gofmt -s" and "gofumpt". I actually like how gofumpt formats stuff but ... nobody else on the team would have it, so it would make things worse.

You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing. I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple…

No, you'd likely get unrelated style changes in your commits. Read the gofumpt readme to understand why.

Re: Reformatting 100k Files at Google in 2011

#138

Post by dmurray »

cmcaine wrote: post #137
dmurray wrote: post #132

Earlier quoted context omitted.

You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing. I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple…

No, you'd likely get unrelated style changes in your commits. Read the gofumpt readme to understand why.

I see! Seems like neither formatter is completely rigid, and both respect some style decisions made by the programmer, so this level of automated reformatting isn't possible.

Re: Reformatting 100k Files at Google in 2011

#139

Post by josephg »

autarch wrote: post #129
josephg wrote: post #127

Earlier quoted context omitted.

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…

> It's easier to read and refactor code when it's all formatted the same way.

Sometimes it matters: indentation, naming_style and bracing should match throughout a codebase.

Sometimes it makes no difference: I really don't care about the order of your import statements. It simply doesn't need to be consistent throughout a program. It doesn't matter.

And sometimes making code "all formatted the same way" makes it all worse. I think thats true for spacing between functions. Functions simply shouldn't have the same spacing between them. Nor should lines of code within a function. Whitespace is a wonderful tool for telling the reader how lines of code group together. Gofmt erases all of that to make sure "code is formatted in the same way" - but in doing so, readability is actively decreased.

> 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?

Thats up to you! Why does everything have to have a right and a wrong answer? Obsessing over this stuff is a pointless waste of time. I guess thats the point of gofmt & friends - that you don't need to think about it. But, you can also not think about it by just not thinking about it, and letting your codebase be a bit inconsistent. Its not a crime. There are no consistency police. You won't go to jail.

> Why do you need to put your mark on code at work? It's not _your_ code.

You have an identifiable style whether you like it or not. Its evident in how you name your functions and variables. In how you write your comments, and where you put them. How you order functions, and where and when you split code between files, classes and modules.

Your style is inescapably everywhere in your work. And it will always have been written by you, long after you're gone.

Are you ashamed of how you write code? Why go out of your way to write and run tools that delete your mark on your work? It doesn't make the code better. Your team will not be more productive as a result. And it doesn't improve quarterly profits.

Like it or not, we're "creatives": That is, we're people who create. The software we write is distinctly our own. Having a little pride in our work is a very healthy thing.

Re: Reformatting 100k Files at Google in 2011

#140

Post by jaeckel »

dmurray wrote: post #132
jrockway wrote: post #102

Earlier quoted context omitted.

Helpfully, you can debate between "gofmt", "gofmt -s" and "gofumpt". I actually like how gofumpt formats stuff but ... nobody else on the team would have it, so it would make things worse.

You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing. I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple…

> [...] nor tooling that makes it a really natural thing to do [...]

If we ignore the fact that switching between those two formatters would "break" the formatting: There exist clean&smudge filters in Git, which could accomplish this technically.

https://git-scm.com/docs/gitattributes#_filter https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

Post reply on HN