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

151–160 of 162 posts

Re: Reformatting 100k Files at Google in 2011

#151

Post by freedomben »

spc476 wrote: post #134
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?

I think that is what GP was saying:

> [Root cause: We could fix this by promoting people for doing that repeat work. But we don't. We promote for the initial sprint.]

Re: Reformatting 100k Files at Google in 2011

#152

Post by paulddraper »

fragmede wrote: post #136
paulddraper wrote: post #60

Earlier quoted context omitted.

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.

You can write a lot (but not all) Python on one line.

And my IDE makes it very easy to indent a snippet.

Re: Reformatting 100k Files at Google in 2011

#153

Post by refulgentis »

ukuina wrote: post #116
refulgentis wrote: post #91

Earlier quoted context omitted.

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?

Maybe I cant remember right, but IIRC any IDE in use there (same ones as outside, there's nothing special) had a setting for tabs vs. spaces / indentation size

And yes, that doesn't help you if ex. your style is a blank line following every code line.

In practice, it works, I surmise because people are fine with someone else's code being in a different style, but they want to write in their style.

Re: Reformatting 100k Files at Google in 2011

#154

Post by duped »

jenadine wrote: post #78
duped wrote: post #69

Earlier quoted context omitted.

Language servers usually are designed around full/concrete syntax trees instead of ASTs for exactly this reason. Adding error nodes to the AST is a hack that hurts more than helps. More technically, language servers usually have a CST that they use to build the AST incrementally, and the AST contains references back to the CST that generated it. This is what allows you to handle incremental text edits and compile sma…

What's wrong with error node in the ast? I've seen language server that completely ignores the parts with error, and I much prefer error nodes because then I still know there is something and these error node can still have children

There are a few problems with errors-as-nodes in a syntax tree. An abstract syntax tree is a hierarchical representation of the program in the language's grammar - and errors are not members of the grammar (they're everything else!)

There is also the problem that an error returned by a language server is a class of a "diagnostic" that includes syntax errors, semantic errors, warnings, lints, etc, associated with a span in the source code. It's much easier to think of diagnostics as a separate data structure that gets filled up during lexical/semantic analysis and associated with spans in the full syntax tree (you can even store them there as fields, but they don't necessarily have children). Then it's obvious how the structure gets created and fed back to the user.

And finally, the whole point of an AST is to be a valid canonical representation of a program so the compiler query it drives doesn't have to do additional input validation. So it just makes the queries/compiler passes easier to write.

Re: Reformatting 100k Files at Google in 2011

#155

Post by fragmede »

jerf wrote: post #147
fragmede wrote: post #135

Earlier quoted context omitted.

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

The meta would say that if people were optimally spending their time on things that matter to them. They don't. If they did bikeshedding wouldn't exist. It obviously does. This is basically the same claim that economics can treat humans as perfectly rational actors perfectly rationally pursuing their perfectly rational goals. It is not a good model of humanity.

It's a revealed preference and there's a ton of economic studies about that vs stated preferences. You can say you don't care about tabs vs spaces all you want, but if you spend hours online talking about it, people are going to think you care, no matter what you say. Bringing economics into this, how do you metricize caring? Can you simplify it to be the time and money you put into a thing?

"All models are wrong, but some are useful." -G. Box

Re: Reformatting 100k Files at Google in 2011

#156

Post by Dagger2 »

troad wrote: post #22

The use of light grey text on a darker grey background strains my eyes and makes this unnecessarily unpleasant to read. I'd respectfully suggest increasing the contrast dramatically. I keep a quick little scriptlet in my bookmark bar for cases like this: javascript:(function(){ $('head').append(' *{color:#101010 !important; background:#f0f0f0 !important;} '); }()); (A ten second hack job; suggested improvements from…

I've been using this:

    javascript:(function() { for (var n of document.querySelectorAll('a, p, li, div')) { n.style.color = (n.nodeName == 'A' ? 'LinkText' : 'CanvasText'); n.style.backgroundColor = 'Canvas'; n.style.font = '500 16px/1.4em sans-serif'; }})();
It uses system colors and thus, if your browser supports them, should adapt to dark mode automatically. Using .style has the advantage that sites can't override the style themselves using .style. (You'd think looping over all these elements would be slow, but it's not.) This version also works on sites that aren't using jQuery, although it wouldn't be hard to use `var s = document.head.appendChild(document.createElement("style")); s.innerText = "...";` for that.

I was surprised at how helpful forcing the font face and spacing is. There's a lot of sites out there with bad-looking fonts or huge line spacing on top of unreadably-light gray.

I added the background color part based on your version. Thanks for prompting me to try that; the way my bookmarklet didn't work on black backgrounds was occasionally a problem. I also added a bit to force link colors, since neither of our versions handled those well.

Perhaps the next step is a "multistage" bookmarklet that applies more rules the more times you click on it, so the more forceful rules (like background color, which often messes up other parts of the site design) can be optional.

Re: Reformatting 100k Files at Google in 2011

#157

Post by icholy »

josephg wrote: post #119
icholy wrote: post #113

Earlier quoted context omitted.

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

Whitespace is useful in normal prose because it has no inherent visual structure aside from punctuation. A programing language is inherently structured into logical functions and blocks. If your function is so complex that you need to start adding whitespace to make it visually parseable then that's its own problem.

Re: Reformatting 100k Files at Google in 2011

#158

Post by josephg »

icholy wrote: post #157
josephg wrote: post #119

Earlier quoted context omitted.

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

Whitespace is useful in normal prose because it has no inherent visual structure aside from punctuation. A programing language is inherently structured into logical functions and blocks. If your function is so complex that you need to start adding whitespace to make it visually parseable then that's its own problem.

Let’s look at a real example. Here’s the source code for binary search from rust’s standard library:

https://doc.rust-lang.org/src/core/slice/mod.rs.html#2786-28...

The function is pretty short - 40 lines including comments. Despite how short the function is, it still uses whitespace to separate and group adjacent lines of code. Personally, I find the code more readable like this. Indentation makes syntactic blocks obvious (the while loop and if statement). But there are also conceptual groupings between lines that mean nothing to the compiler, but are semantically meaningful to humans. I can tell at a glance that the comment about safety is most associated with that one line below the comment. And so on.

I think this code would be worse if we deleted the whitespace. How would you improve this code?

Re: Reformatting 100k Files at Google in 2011

#159

Post by troad »

Dagger2 wrote: post #156
troad wrote: post #22

The use of light grey text on a darker grey background strains my eyes and makes this unnecessarily unpleasant to read. I'd respectfully suggest increasing the contrast dramatically. I keep a quick little scriptlet in my bookmark bar for cases like this: javascript:(function(){ $('head').append(' *{color:#101010 !important; background:#f0f0f0 !important;} '); }()); (A ten second hack job; suggested improvements from…

I've been using this: javascript:(function() { for (var n of document.querySelectorAll('a, p, li, div')) { n.style.color = (n.nodeName == 'A' ? 'LinkText' : 'CanvasText'); n.style.backgroundColor = 'Canvas'; n.style.font = '500 16px/1.4em sans-serif'; }})(); It uses system colors and thus, if your browser supports them, should adapt to dark mode automatically. Using .style has the advantage that sites can't override…

Thank you, this is great! I hadn't considered changing the font for greater readability, but it's an obvious improvement. Good job with the links, too, that was a great idea. I've added 'blockquote' to your tag list, since I find that often gets a background shade of its own (e.g. code snippets), but otherwise I've saved it as is.

I tend to prefer interfaces in dark mode and content in light mode, so I'll see how I feel about the conditional logic there, I may eventually wind up going back to hardcoding some colours.

> Perhaps the next step is a "multistage" bookmarklet that applies more rules the more times you click on it, so the more forceful rules (like background color, which often messes up other parts of the site design) can be optional.

That's a really neat idea. I can imagine it stretching from slight readability tweaks all the way to a pseudo-reader mode. It would definitely be a bit more of an undertaking than either of our quick snippets, though.

Re: Reformatting 100k Files at Google in 2011

#160

Post by icholy »

josephg wrote: post #158
icholy wrote: post #157

Earlier quoted context omitted.

Whitespace is useful in normal prose because it has no inherent visual structure aside from punctuation. A programing language is inherently structured into logical functions and blocks. If your function is so complex that you need to start adding whitespace to make it visually parseable then that's its own problem.

Let’s look at a real example. Here’s the source code for binary search from rust’s standard library: https://doc.rust-lang.org/src/core/slice/mod.rs.html#2786-28... The function is pretty short - 40 lines including comments. Despite how short the function is, it still uses whitespace to separate and group adjacent lines of code. Personally, I find the code more readable like this. Indentation makes syntactic blocks o…

All of the blank lines can be deleted from that function without reducing the readability.
Post reply on HN