   [C++] Coding Styles
  (Sorry if this is the wrong section. I figured this would go in either General Programming or Software Engineering.)There are many coding styles in use today by C++ programmers. I find this to be problematic, as I am unable to find a common ground to make my code look unified. It's bad enough that Windows programmers have to mix and match standard C++ and Microsoft styles, and when third party libraries are brought into the picture, everything sort of goes to hell.The standard C++ libraries have everything in lower case, with keywords separated by underscores (i.e. std::vector::push_back()). Microsoft's code on the other hand uses upper case for all structures (i.e. WNDCLASSEX) while capitalizing the first letter of each keyword in function names (i.e. MessageBoxA()). What's worse is that Hungarian notation is everywhere, and it's ugly.For the past couple of months I've been trying to find the ideal coding style for me to use in my projects. I understand that I'm just going to have to deal with C++, Microsoft, and third party naming conventions. As for my coding style, I've tried just about everything, but nothing seems completely satisfactory. Right now I'm experimenting with a standard C++ style (lower case, underscores for separation, abbreviation, etc.). I have a number of questions regarding coding styles, and I would be happy to see what the general consensus is.1.) What sort of style do you prefer when naming classes? (CPerson, person, etc.)2.) How do you name member variables in a class? I thought that it made sense to prefix members with m_, but when I want to make some members of a class public, it looks ugly to access members from outside the class. I also tried using trailing underscores but they're quite annoying, plus I'm wary about using underscores anywhere outside of the middle of a declaration.3.) How do you name functions that are part of a class? (DoSomething(), doSomething(), do_something(), etc.)4.) How do you name structures and their members?5.) How do you name functions that are not part of a class?6.) How do you name variables that are not part of a class?7.) How do you name constants and enumerations?Thank you for your time.   
  Coding habits are subjective and can not be expected to be a certain way.Quote:The standard C++ libraries have everything in lower case, with keywords separated by underscores (i.e. std::vector::push_back()). Microsoft's code on the other hand uses upper case for all structures (i.e. WNDCLASSEX) while capitalizing the first letter of each keyword in function names (i.e. MessageBoxA()). What's worse is that Hungarian notation is everywhere, and it's ugly.Microsoft chose a convention that works for them. Why is that bad?Quote:For the past couple of months I've been trying to find the ideal coding style for me to use in my projects. I understand that I'm just going to have to deal with C++, Microsoft, and third party naming conventions. As for my coding style, I've tried just about everything, but nothing seems completely satisfactory. Right now I'm experimenting with a standard C++ style (lower case, underscores for separation, abbreviation, etc.). I have a number of questions regarding coding styles, and I would be happy to see what the general consensus is.My advice: Stop caring. There are reasonable standards such as clear, concise, and non-collidable names, but habits variate. How do you wish to control your workflow? If you are strongly for the idea of literate programming, write code that looks as much like plain English as possible. If you hate losing your "flow" like me, type everything in lower case or Camel notation and avoid cumbersome keys like the underscore. (This isn't to say you should ignore writing clear, readable code. Take the time to indent properly, comment, etc.)Our habits are just as subjective as anyone else's, and you won't exactly learn anything if we took your survey. And please, do not try to find some compromise style between all other ones. I don't think one can be found. Just write clear code with some conventions to differentiate between constants, functions, etc. If all else fails, search the net and read other people's code until you find a style you like, and adopt it.Hope this helps!   ;  There's several different recognised styles and each 3rd party uses it's own style, so it's inevitable the problem you mentioned. I don't think it matters the particular style you choose, what matters is consistancy. Having all your code written in one consistant style speeds up development.   ;  Before complaining about hungarian, you should take note that there's two styles of it - "Apps Hungarian", which is the real one (invented by a Hungarian guy), and there's "System Hungarian", which is Microsoft's bastardisation of it (not recommended in 99% of situations).I use a microsofty style, but when using 3rd party libraries I use their style. If I made a wrapper for a 3rd party library, the wrapper's interface would be in my style, but it's internals would be mostly in their style.1.) class CPerson, template class TPerson, struct Person2.) m_ + apps hungarian. Structs are used for 'public' data-only classes, so I drop the m_ for struct-members.3.) DoSomething()4.) see 1/25.) DoSomething()6.) g_ or s_ for global/static respectively.7.) enum Person { personOccupation1 }#define CONSTANT 42const int local = 42;static const int s_fileLocal = 42;namespace { const int s_fileLocal = 42; }static const int s_classLocal = 42;   ;Quote:Original post by zyrolastingCoding habits are subjective and can not be expected to be a certain way.Quote:The standard C++ libraries have everything in lower case, with keywords separated by underscores (i.e. std::vector::push_back()). Microsoft's code on the other hand uses upper case for all structures (i.e. WNDCLASSEX) while capitalizing the first letter of each keyword in function names (i.e. MessageBoxA()). What's worse is that Hungarian notation is everywhere, and it's ugly.Microsoft chose a convention that works for them. Why is that bad?I didn't say it was bad, but I think that they could have done better.Quote:Original post by zyrolastingQuote:For the past couple of months I've been trying to find the ideal coding style for me to use in my projects. I understand that I'm just going to have to deal with C++, Microsoft, and third party naming conventions. As for my coding style, I've tried just about everything, but nothing seems completely satisfactory. Right now I'm experimenting with a standard C++ style (lower case, underscores for separation, abbreviation, etc.). I have a number of questions regarding coding styles, and I would be happy to see what the general consensus is.My advice: Stop caring. There are reasonable standards such as clear, concise, and non-collidable names, but habits variate. How do you wish to control your workflow? If you are strongly for the idea of literate programming, write code that looks as much like plain English as possible. If you hate losing your "flow" like me, type everything in lower case or Camel notation and avoid cumbersome keys like the underscore. (This isn't to say you should ignore writing clear, readable code. Take the time to indent properly, comment, etc.)Our habits are just as subjective as anyone else's, and you won't exactly learn anything if we took your survey. And please, do not try to find some compromise style between all other ones. I don't think one can be found. Just write clear code with some conventions to differentiate between constants, functions, etc. If all else fails, search the net and read other people's code until you find a style you like, and adopt it.The problem is that I can't stop caring because I am always aware that someone someday may look at my code, and I want them to be able to read it easily. I want a style that meshes everything together nicely, but I am unable to do this without further research. The reason I asked questions about how you guys did things is simply because I need more ideas on how I can integrate certain features of the language more clearly into my style.Quote:Original post by HodgmanI use a microsofty style, but when using 3rd party libraries I use their style. If I made a wrapper for a 3rd party library, the wrapper's interface would be in my style, but it's internals would be mostly in their style.1.) class CPerson, template class TPerson, struct Person2.) m_ + apps hungarian. Structs are used for 'public' data-only classes, so I drop the m_ for struct-members.3.) DoSomething()4.) see 1/25.) DoSomething()6.) g_ or s_ for global/static respectively.7.) enum Person { personOccupation1 }#define CONSTANT 42const int local = 42;static const int s_fileLocal = 42;namespace { const int s_fileLocal = 42; }static const int s_classLocal = 42;A further question about #2: Would you keep the m_ prefix if a class member variable is public?   ;Quote:Original post by KuraitouA further question about #2: Would you keep the m_ prefix if a class member variable is public?It's extremely rare (for me) to have a public member in a class that also has private members. I usually have OO-style classes with public methods and private data, or C-style structs with just public data.If the members of the class/struct are public, then yeah, I drop the m_.If it's an OO-style class though, I'd probably write:int Member() const { return m_Member; }void Member( int i ) { m_Member = i; }Though, yes the above getter/setter for the point of having a getter/setter is pretty useless. I'd probably look at that class and ask myself why that variable is even in the class to begin with...   ;Quote:Original post by KuraitouI didn't say it was bad, but I think that they could have done better.Microsoft's naming convention is ~20 years old, and was design for pure C API.All things considered, they did OK. I'm even going to claim that WinAPI is very consistent. Verbose or somewhat redundant, but that is mostly consequence of language.But going beyond mere naming convention, the important aspect to understand about WinAPI is how it manages resources, and why. IOC, the fairly recent "patterned" designs are much closer to WinAPI's design (or other procedural/modular approaches) than to other OO concepts. And IOC is generally considered a good way to approach design these days.Microsoft's C++ wrappers, as well as MACROed proxies also carry quite a lot of lessons with regard to legacy interoperability.It's somewhat sad that these kind of topics are not really analyzed or taught. It's easy to dismiss them as dated or irrelevant, yet people who designed things that last 20, 30, 40+ years might have done something right. And where they went wrong.   ;Quote:There are many coding styles in use today by C++ programmers. I find this to be problematic...The problem is that I can't stop caring because I am always aware that someone someday may look at my code, and I want them to be able to read it easily.If the problem is that there are too many different coding styles, why bug people to share more? Nothing is wrong with your philosophy of writing clean code, but what I'm trying to tell you is that it's more productive to focus on your own style without dwelling on how others do things. In my experience, an external self-image slows things down and scrambles existing projects. I found a style that worked for me by looking at/trying other styles and finding what I initially thought was a "compromised" position, but it turned out to be another extreme that focused more on my needs than anyone else's. I refined my habits to be cleaner and more productive over time, and you will do the same thing as long as you keep reading and writing code.Treat your style like another creation. If what we think about your decisions is really that important, write some code in a style you'd like to try, post it up here, and ask for feedback. I'll be happy to give my view on snippets if I see them.   ;  Just choose one style that you like best, or that you think that achieves what you want;I think the important thing is to keep it consistent through the code. That way a person reading your code will have to get used to your style at the very beginning but soon it will be no problem to follow the rest.I myself like to use m_ for a class member variable, l_ for local variables and no prefix for arguments. Also, I write function names starting with capital letter and separated by underscore sometimes, or with capital letter for each word.   ;  I don't prefix anything. ;)Just sometimes, for very important classes I put a "W" in front of the class name -> Engine name = [w]tech. For makros I do this:#define DoFoo(x) x=x*x/x+x-xFor constants, which are just numbers (Or so):#define CONSTANT 1When a constant is something important, like a Button ID or so, I do#define ID_SaveButtonFunctions/Classes/Structs I dovoid MyFunction()