Google C++ style guide • Hacker News Board

Re: Google C++ style guide

#51

Post by shmerl » Thu, Apr 10, 2014, 1:39 PM UTC

romanovcode wrote: post #34

shmerl wrote: post #24

> Functions should start with a capital letter and have a capital letter for each new word. No underscores. Why so? It's Java-ish. Java favors camel notation for some historic reason. C++ on the other hand favors snake notation which is clearly reflected in stdc++. Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference, I just wonder w…

>Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference. Exactly. It's matter of preference. I can read TextLikeThis much easier than text_like_this. Granted I've been developing in C# for past few years so that's likely the reason.

It's a matter of preference, however it's not a subjective thing that reading the text without spacing between the words is slower. There are tests which measure such speed.

Re: Google C++ style guide

#52

Post by jsnell » Thu, Apr 10, 2014, 2:13 PM UTC

fhd2 wrote: post #10

The C++ you end up with by following Google's style guide is more of a "C with classes" thing, they prohibit several central features of C++. That said, I understand that they mostly do this to be consistent with their older code bases. But it's not exactly a style guide I'd follow strictly in a new project/team.

It's a totally reasonable style guide to adopt with a new project / team. And in fact it's what I chose the last time I started a team doing systems programming. It's well reasoned, and hits my personal sweet spot for the power vs. complexity tradeoff.

C++ has a pretty bad reputation. Possibly deservedly. So unless everyone has already bought fully into C++, the full language is a very hard sell. But C with a few extra conveniences and safety features (strings, unique_ptr, some limited polymorphism) is a much easier one.

Re: Google C++ style guide

#53

Post by Kranar » Thu, Apr 10, 2014, 10:47 PM UTC

brianpgordon wrote: post #43

nemasu wrote: post #8

I love C++, I wish there was more work available that used it. EDIT: Clearly my issue is where I lived, not the lack of available jobs apparently.

I don't really see a lot to like about C++. It's huge and fiendishly complex, keywords are overloaded to incomprehensibility, it doesn't make satisfactory guarantees about static initialization, exception safety is too hard to reason about, it's full of features maintained for backwards compatibility even when they no longer make sense, and development tools are unacceptably inferior to Java and C#. Pros are that it…

>It's huge and fiendishly complex

It's used to write software where that complexity is a minor cost in return for the performance it provides.

>keywords are overloaded to incomprehensibility

I don't know of a single keyword that is incomprehensible. Only a few keywords are overloaded but they are overloaded in contexts that make it very very clear what they're being used for.

>doesn't make satisfactory guarantees about static initialization

It makes very strong guarantees about static initialization. Static variables declared within a function are initialized when control flow passes through it for the first time, and such initialization is guaranteed to be thread safe. Global variables have three phases to their initialization, zero initialization, static initialization, and then dynamic initialization. Global variables are also initialized in the order that they are defined within a translation unit.

> exception safety is too hard to reason about

Exception safety is easier to reason about in C++ than any other language thanks to RAII.

>it's full of features maintained for backwards compatibility even when they no longer make sense

They make sense because no one wants to rewrite the billions of lines of code that their project might depend on that uses those features. Instead, it makes a lot more sense to just avoid using deprecated or backward compatible features rather than remove them from the language and break a crap load of invaluable software in the process.

>development tools are unacceptably inferior to Java and C#.

This is true.

Re: Google C++ style guide

#54

Post by yoklov » Fri, Apr 11, 2014, 1:03 AM UTC

romanovcode wrote: post #50

yoklov wrote: post #47

Earlier quoted context omitted.

I don't have a strong opinion either way (I probably like snake case more, but use camel/pascal case basically everywhere) but this doesn't work as well when acronyms are involved. e.g. is it XmlParser or XMLParser? I'd say the latter, but someone else might disagree. I think there are more ambiguous examples, but cant think of them.

> is it XmlParser or XMLParser? MS standards says that if shortened letter combination is longer than 2 words than it's lowered, otherwise everything is uppercase. e.g. XmlParser, IOStream But again, everyone can create their own standard and be happy. The only problem occurs when you work with 10 people and everyone is sticking to his own style.

Not every API is that consistent. JavaScript's `XMLHttpRequest`, for example...

Re: Google C++ style guide

#55

Post by brianpgordon » Fri, Apr 11, 2014, 4:46 AM UTC

Kranar wrote: post #53

brianpgordon wrote: post #43

Earlier quoted context omitted.

I don't really see a lot to like about C++. It's huge and fiendishly complex, keywords are overloaded to incomprehensibility, it doesn't make satisfactory guarantees about static initialization, exception safety is too hard to reason about, it's full of features maintained for backwards compatibility even when they no longer make sense, and development tools are unacceptably inferior to Java and C#. Pros are that it…

>It's huge and fiendishly complex It's used to write software where that complexity is a minor cost in return for the performance it provides. >keywords are overloaded to incomprehensibility I don't know of a single keyword that is incomprehensible. Only a few keywords are overloaded but they are overloaded in contexts that make it very very clear what they're being used for. >doesn't make satisfactory guarantees abo…

> It's used to write software where that complexity is a minor cost in return for the performance it provides.

Other languages (C, D, Ada, Go) provide similar native performance with far less complexity.

> I don't know of a single keyword that is incomprehensible. Only a few keywords are overloaded but they are overloaded in contexts that make it very very clear what they're being used for.

static, virtual, and class are all overloaded in weird ways. But punctuation is the worst: in particular commas, colons, ampersands, and asterisks are overused to absurdity. I'd almost prefer APL-like extra symbols to disambiguate some of the insane template one-liners that I've seen.

> It makes very strong guarantees about static initialization.

Are you saying that the static initialization order fiasco doesn't exist? C# and Java do not suffer from this problem.

> Exception safety is easier to reason about in C++ than any other language thanks to RAII.

I don't even know what to say to this one. Exceptions are notoriously wonky in C++. The language makes you resort to idioms like RAII and copy-swap to use them at all, instead of providing language-level support to solve those problems.

> They make sense because no one wants to rewrite the billions of lines of code that their project might depend on that uses those features. Instead, it makes a lot more sense to just avoid using deprecated or backward compatible features rather than remove them from the language and break a crap load of invaluable software in the process.

And as a consequence the language suffers. Historical reasons are not a valid defense of the present design of the language.

I am reminded of this esr quote:

"While we do not intend to insult the designers of C++, we will not make excuses for them either. They repeatedly made design choices that were well-intentioned, understandable in context, and wrong."