Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google C++ style guide

google-styleguide.googlecode.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Google C++ style guide

#41

Post by MichaelMoser123 »

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.

Actually they do prohibit those features that arguably cause more damage than benefit.

c++ exceptions? in an unmanaged (runtime engine not managed by some sort of VM) language you can't really assume anything when an exception occurs, you can't assume that you will be able to allocate more memory from the heap, for instance - if the heap is corrupted then this will just not work.

RTTI ? it costs a lot, well and you can do without it; Besides requirement of RTTI (assuming that the library does RTTI) will prevent you from using third party libraries that might be of use. Resolution: skip.

Re: Google C++ style guide

#42

Post by fauigerzigerk »

brianpgordon wrote: post #40
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.

You're right on the money. This passage is particularly damning: > Rvalue references encourage a programming style that makes heavier use of value semantics. This style is unfamiliar to many developers, and its performance characteristics can be hard to reason about. It's like, do you know C++ or don't you? Value semantics are C++.

They are right that it's harder to reason about value semantics. The cost of passing a pointer is always the same whereas the cost of passing a value isn't.

But I don't think that's a good enough reason not to prefer values considering the performance and memory usage drawbacks of shared_ptr. unique_ptr is often the best solution in my view.

Re: Google C++ style guide

#43

Post by brianpgordon »

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 performs excellently and const correctness is pretty cool.

Let's get an old fashioned debate started!

Re: Google C++ style guide

#45

Post by eksith »

"Use only spaces, and indent 2 spaces at a time." Of course you realize, this means war.

Much like all other style guides I've come across, there are a lot of hints that I'll find helpful and encourage at our next meetup, but honestly, the only style guide that truly matters is the one you can all agree to in your team and makes sense in your context.

And, I'm not sure if this is just those who share the same water cooler, many C++ devs seem to dislike using STL. I can't figure out why.

Re: Google C++ style guide

#46

Post by cubbimew »

It doesn't get any worse than that guide (except maybe EC++ or the FQA). No RAII, no class invariants, no value semantics, no streams, no operators (which means no custom Iterators, EqualityComparable or even CopyAssignable types! Such a basic feature called "insidious"). Not even mentioning the FUD about newer C++ features.

Re: Google C++ style guide

#47

Post by yoklov »

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.

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.

Re: Google C++ style guide

#48

Post by yoklov »

eksith wrote: post #45

"Use only spaces, and indent 2 spaces at a time." Of course you realize, this means war. Much like all other style guides I've come across, there are a lot of hints that I'll find helpful and encourage at our next meetup, but honestly, the only style guide that truly matters is the one you can all agree to in your team and makes sense in your context. And, I'm not sure if this is just those who share the same water c…

The big reasons for avoiding the STL are (in my experience)

1. Holdover from when STL implementations were buggy

2. Holdover from C

3. Avoiding exceptions it might throw if you compile with exceptions off

4. Many STLs are slow and unoptimized.

5. Many parts of the STL are slow, no matter which STL you use

6. Poor allocator support (better, not perfect in c++11)

7. You need guarantees that the STL doesnt provide.

there are more, but those are the big ones.

Re: Google C++ style guide

#49

Post by dsymonds »

brianpgordon wrote: post #44
frozenport wrote: post #35

Does Google's 80 character limit include the identification sequence?

You'd think that with their mountains of cash Google could afford to replace their engineers' 80-character monochrome terminals.

Actually you find that many engineers with 30" monitors end up using multiple side-by-side terminal windows, each set to 80 chars.

Re: Google C++ style guide

#50

Post by romanovcode »

yoklov wrote: post #47
romanovcode wrote: post #34

Earlier quoted context omitted.

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

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.

Post reply on HN