3 ms·

I do not write C++ often as i'm not a fan of the language, but when i do... i don't follow any of these :-P. I have my own style which is pretty much an "evolut

I do not write C++ often as i'm not a fan of the language, but when i do... i don't follow any of these :-P. I have my own style which is pretty much an "evolution" of what i see a lot of C++ projects, mainly from the MSVC/Windows world, use. In short, whitespace is mostly Allman style with spaces for indentation. Names use mostly CamelCase, with some exceptions. Public members go first, protected members go middle, private members go last. Instance fields have an m_ prefix, static fields that have an s_ prefix and both use javaCase instead of CamelCase. Function parameters and local variables also use javaCase. In the cases where javaCase is used, whenever possible single word identifiers are used. Classes have a C prefix except mixings which have an M prefix and interfaces which have an I prefix, structs have an S prefix, enums have an E prefix, namespaces have an N prefix, templates have a T prefix (not C/S, etc), function types have an F prefix, typedefs meant for aliasing have an A prefix. Exported/imported global variables have a G prefix, static toplevel variables have an L prefix. Macros all in all caps with underscores separating words. Pointer and reference declarations have the start/ampersand right after the type name, whenever possible there is a single declaration per line and only a single pointer/reference use (using aliases for more complex stuff). All types are declared in the global namespace, however functions are grouped in topic-specific namespaces. When inheriting a class and overriding virtual methods, the overrides are declared in a separate block in the class with the comment "// Baseclass methods" or something like that. Other members have a single line documenting their purpose (no doxygen, plain text, i find doxygen comments to be noise, if there is need for explicit documentation it should be in a separate file). There are other minor things, like how header files are laid out, "getter" functions that only return a private/protected member being inlined, etc but the above are the main stuff. I do not have any of these rules written out anywhere, i just happen to "grow" to write C++ code like that over time. Interestingly my C code style is totally different (snake_case, _t suffix for types, _s suffix for structs, etc). Here is an example: https://pastebin.com/anLvHRQ2 https://pastebin.com/anLvHRQ2 It is the model document (as in document/view) for the mesh editor in this video: https://www.youtube.com/watch?v=rr1Sr9hTkzg https://www.youtube.com/watch?v=rr1Sr9hTkzg

asveikau 8y ago
This is how a huge chunk of the Windows or Windows-trained world writes C++. You don't have to like it but it's recognizable and common.
- badsectoracula 8y ago
  Yes, especially the m_, I, C, S, E and G stuff are very common. I think it comes from MFC. The T stuff is less common - in my current company templates are also C-prefix, but in the previous company i worked at they were T-prefixed. Some other stuff like L, F, A, s_, etc are things i came up with myself for my own code (for work code i use whatever others are using) since i didn't like the more common uses (in the previous company i worked at statics were also S prefixed, but i wanted something to separate from structs so i used L for "local"). Of course once you get used to the common style above, these "extensions" are mostly obvious so i'm certain that others are using them too.

asveikau 8y ago

This is how a huge chunk of the Windows or Windows-trained world writes C++. You don't have to like it but it's recognizable and common.

badsectoracula 8y ago
Yes, especially the m_, I, C, S, E and G stuff are very common. I think it comes from MFC. The T stuff is less common - in my current company templates are also C-prefix, but in the previous company i worked at they were T-prefixed. Some other stuff like L, F, A, s_, etc are things i came up with myself for my own code (for work code i use whatever others are using) since i didn't like the more common uses (in the previous company i worked at statics were also S prefixed, but i wanted something to separate from structs so i used L for "local"). Of course once you get used to the common style above, these "extensions" are mostly obvious so i'm certain that others are using them too.