Valve C++ style guide?

[dude]

Hey I was just reading through the source for SteamVR and Steamworks and I've been a bit confused by some of the coding conventions. Specifically certain prefixes being used in variable names such as "bool m_bIOFailure;" that I have noticed across multiple API's from Valve.

I understand it must have some kind of meaning, but it's super confusing without that context. Can any Valve developers shed light on this or possibly share your internal style guide with us?

[henryg]

Valve's C++ style is a bit haphazard, but it evolved out of common Windows programming standards in the late 90s. You can google "Hungarian notation" to find out some of the history here.

In general, we tend to use scope-indicating prefixes: g_ for globals, s_ for file-scope or function-scope statics, m_ for struct or class members. The first characters of the variable name after the scope prefix indicate the type and/or intended purpose of the variable: "b" for boolean flag, "un" or "n" for (unsigned) numbers, "i" for an index, "c" for a counter, etc. They can be combined with various levels of "p" to represent indirection: m_ppunValue is a member variable which is a pointer to a pointer to an unsigned integer, and would be declared as "uint **m_ppunValue;"

For type names, we like the _t suffix for simple / plain-data types and a C prefix for complex C++ classes. (This is all a bit fungible and we break our own rules from time to time.)

Now that modern code editors include automatic variable completion and reasonable tooltips/hints about variable types and scopes, these 90's-era conventions have lost a lot of their value. But we keep going out of inertia and consistency, and because we're all used to them by now.

[dude]

Originally posted by henryg:

Now that modern code editors include automatic variable completion and reasonable tooltips/hints about variable types and scopes, these 90's-era conventions have lost a lot of their value. But we keep going out of inertia and consistency, and because we're all used to them by now.

I'd say there's still a lot of value in being able to fully understand the exact input/ouput of a function at a glance. I've seen similar patterns used in Javascript development so I figured that must be what it was.

Anyways, thanks for the detailed response!

[o-super]

Thanks for your feedback henryg.