Comment by CoolGuySteve | Hacker News Reader

Comment by CoolGuySteve | Hacker News Reader

While it's very popular, I find Google's to be the most distasteful. It's very opinionated in a very curmudgeonly kind of way.

In particular, the emphasis on 80 char wide lines hurts readability by encouraging shorter variable names and wastes quite a bit of vertical space. For example, this example line from the spec violates the spec: "using TimeSeries = std::unordered_set<DataPoint, std::hash<DataPoint>, DataPointComparator>;"

And it's strangely opinionated but in way that's particularly fearful of templates, macros, and SFINAE such that it causes more strife than it's worth. Like by forcing you to justify otherwise reasonable things like "template<typename Thing> RedisSerializeTheThing(const Thing& thing);" or "template<typename Thing> LexicalCastLoggerThatCanOptionallyTemplateSpecialize(const Thing& thing);"

Variadic templates fall under the template ban I guess and __VA_ARGS__ stuff is based around macros, so there's not really any good way under that standard to express something like a safer sprintf or tuple marshalling.

Essentially my problem with the guide is that it bans a lot of type-inference that makes C++ safer and faster. C++ is already dangerous, so I think that's the wrong choice.

The Google style guide developed over time through iterations involving several thousand programmers. It's the culmination of all those programmers and operational aspects which got it to this point. So when you say it's 'opinionated', the data has said the styling in the document is the right thing to do.

That's a funny way of putting it, almost like an appeal to tradition.

It reads more like Google had to herd a lot of junior programmers and rather than teaching better judgement or patterns, just walled off huge sections of the language completely.

Is there any other way at google scale?

I haven't written more than 100k LOC of C++ and yet there are already lots of code (mostly template meta programming) that I wrote that even I can't read anymore.

Now imagine blowing that up to (literally) billions of lines of C++ written by overly clever engineers all eager to prove themselves.

Quite a few things:

- Allow whatever C++ inside the project but force each project to export a plain C API and .so file. This has the quadruple bonus of (1) avoiding ABI problems between compilers, (2) hiding complexity from other teams, (3) forcing teams to think more about their APIs, and (4) being trivially callable from any other language.

- Large API/SPI review mailing lists. This worked quite well at Apple.

- Add a section to the style guide about what's appropriate template use and what's not. Banning one of the language's most important features is just a cop out.

- Better mentorship from senior engineers.

The template ban was made because they are Google, which already provides an internal high-quality fundamental C++ library so most people don't have to invent wheels

I think at work we use 120 char limit, with klang formatter making it so you don't have to think about it much.

80 seems excessive, but no limit means having to horizontal scroll or even resize windows in an aggravating way. Some sort of limit is a good thing. Vertical monitors can also be great, but are limited in horizontal space, making files with long lines a headache to read.

It also made reading code more consistently nice across different views, from diffs to review software.

Python's 79 columns is also insane. But at the same time, it's a weakly held opinion that's broadly overridden in the community. I think it's generally accepted as an obsolete idea.

Having shorter line lengths makes it easier to review diffs side by side (especially 3 way diffs).

The other thing that people do with long lines is that they try to combine a lot of statements per line. Then when that line has to be changed, it's harder to review in a diff (compared to the diff that affects a line containing a single statement).

In practice I just see it screwing up perfectly good lines way more often than long lines causing trouble.

This is one of those matter of opinion things. But it's so wildly one sided from my experience that I struggle to see the other side.

Perhaps one way to look at it is to compare long lines in code with long paragraphs in prose. I'm sure you've seen examples of posts on forums where someone writes a long post, but doesn't subdivide it into paragraphs. While it's possible to read and understand the message it's trying to convey, it's more difficult to do compared to a version that's divided into paragraphs.

Similarly, one can combine several statements in code on a single line, but that, in my opinion, is harder to read compared to having a single statement per line and harder to read the resulting diff when changing something in the line.

This is one example I copied from bashoneliners.com:

  man -k . | awk '{ print $1 " " $2 }' | dmenu -i -p man | awk '{ print $2 " " $1 }' | tr -d '()' | xargs man -t | ps2pdf - - | zathura -

Personally, I would find it easier to read and understand it if it was written as follows:

  man -k . \
  awk '{ print $1 " " $2 }' \
  dmenu -i -p man \
  awk '{ print $2 " " $1 }' \
  tr -d '()' \
  xargs man -t \
  ps2pdf - - \
  zathura -

If I had this in source control and decided to add, remove, or change one of the commands for this oneliner, then it would be far easier to read the diff if it was in the multi-line form compared to the single line form.

Reply on news.ycombinator.com