How to deal with differences in style

in C++ there's many many ways to design your code.

Use templates, OO or functions. Use STL with pointers or copy by value, use namespaces or not.

If every programmer can do what they want you see huge differences in style.
What happens in my company now is that beginner, intermediate and 10+ years C++ programmers have to build a platform and you see exactly this. lots of style differences, me using boost::shared_ptr a lot, others prefer old style pointers.

Now we are trying to agree on one style as much as possible but as usual us stubborn programmers cant agree on anything :)

How is this problem usually fixed? Somebody knowledgable and not in the team decides, vote, discuss forever or everybody can do what they want?

Erm, this is less style and more design.
I say stuff it down their throat. It's better to have flexible and safe code rather than C-ish code that's unsafe.
Your company wants good products out the door soon, right? Easy to maintain and bug-free, right? Then use those as arguments for teaching those other programmers on how to write safe and modern C++ code.

I don't have particular experience on this matter, so this comes from a logical standpoint. But you may take it as you wish.

At the company I worked for, some time ago, we had a wiki on intranet server, that was all about the rules we should apply in our code. It wasn't too strict (in the way it didn't prohibit ?: - but would explain where it was or wasn't appropriate, etc), but had examples and explanations why this this was preferred over that and that. For what I know the company "standard" was born in pain out of long discussions and fights over various things. ;)

I'd say that leaving every coder to his own, wouldn't be the best of ideas. That way one can only work efficiently with ones own code, and when necessity will call to see some other part of it, maintained by somebody else... Oops! Hey, where's Mark, I have to ask him what all this garbage means!

2 words: Code Reviews

They help find bugs in code before it reaches QA or customers, and it helps less experienced developers gain insights from senior developers.

This happens quite a lot IMHO. Not just for design like Elysia said. Yeah, we should make the code safer, flexible, and designed better. However it's all come down to the application itself. Is it a multiplatform one (so you should use the traditional pointer than the boost's shared pointer one, maybe even skipping STL altogether)? Etc.

Secondly, programmers usually behave like a "female dog" if it concerns their programming style (I know I do. :p). Eg. indentation, spaces vs tabs, naming conventions, etc. That's why most open source libraries put a style guide on their code. Eg. using K&R indent style, 5 spaces tab, etc. So I agree with Elysia, stuff it down to their throat. Maybe if they are still developing it locally, they can use their own style. However, before they merge it with the SVN, they should change the style accordingly.

EDIT: LOLs at the swear word filter. :D

Erm, STL and and boost are all about portability. They should only not be used in very special circumstances.

I actually told them that "I had to stuff smart pointers down their throat" but they kinda choked on it.
The arguments not to use a smart pointer:

* ownership is unclear
* you become a lazy programmer by not caring about pointers anymore

So we had a long discussion (without result of course) about if we should use smart pointers or not which proves my original point.
How do other companies deal with the neverending disagreement about code?

Code reviews from seniors is IMO not a good solution either to fix this problem because seniors also disagree on just about anything. And a senior's opinion can be outdated, like where I work one senior learnt C++ pre 1998 and hasnt updated his knowledge since. So he is 100% against the use of templates and smart pointers and whatever other scary modern stuff.

It sounds like you need to kick your company into gear and have them agree on a common coding standard. Or rather, educate those who are uneducated. The company's goal should first and foremost be to create bug-free code in a short amount of time. Then customers will be happy.

Quote:

---

Originally Posted by Elysia

Erm, STL and and boost are all about portability. They should only not be used in very special circumstances.

---

Weird, that's not what Mozilla said:

Quote:

---

Don't use C++ standard library features, including iostream

Using C++ standard library features involves significant portability problems because newer compilers require the use of namespaces and of headers without .h, whereas older compilers require the opposite. This includes iostream features, such as cin and cout.

Furthermore, using the C++ standard library imposes difficulties on those attempting to use Mozilla on small devices.

There is one exception to this rule: it is acceptable to use placement new. To use it, include the standard header <new> by writing #include NEW_H.

---

They are apparently stuck with non-standard compilers on some platforms. For example, on Windows/Linux/Mac, there are very good compilers that implement most things. Thus, it is possible to write fully portable code with all features without worries.
It annoys me that such stupid compilers exist yet today. They should be fixed rather than having to compromise code. But that's reality for you. Mozilla has some special circumstances.

Quote:

---

Originally Posted by KIBO

I actually told them that "I had to stuff smart pointers down their throat" but they kinda choked on it.

---

Instead of stuffing smart pointers down their throat by yourself, refer them to the experts. For example, describe the benefits of RAII, perhaps by showing them Stroustrup's answer to the FAQ How do I deal with memory leaks? Instead of gushing about how great smart pointers are, let Sutter and Alexandrescu do the talking by inviting your audience to read item 13 of C++ Coding Standards. Show them Meyers example of how failing to use a smart pointer can lead to bugs by showing them item 13 of Effective C++, 3rd Edition, and then point out that Meyers' fixed example of using std::auto_ptr is soon to be outdated by std::unique_ptr. Reason that the inclusion of std::unique_ptr in the next version of the C++ standard indicates that the general C++ community is moving towards the use of smart pointers precisely because of the benefits described by Stroustrup, Meyers, Sutter and Alexandrescu.

Quote:

---

Originally Posted by KIBO

The arguments not to use a smart pointer:

* ownership is unclear
* you become a lazy programmer by not caring about pointers anymore

---

You can address the former by pointing that unless it is somehow fixed in code (e.g., by using a smart pointer ;) ) ownership is a matter of documentation and convention to begin with. Whatever a team establishs for pointers can be established for smart pointers. You can address the latter by pointing out that this kind of laziness is a Good Thing since it reduces mistakes. If they disagree point out an example of accepted laziness, e.g., argue that by their reasoning, they should accept that the use of abstractions in general breeds laziness since the abstraction hides details that the programmer need not care about at the level of the abstraction.

Quote:

---

Originally Posted by laserlight

Instead of stuffing smart pointers down their throat by yourself, refer them to the experts. For example, describe the benefits of RAII, perhaps by showing them Stroustrup's answer to the FAQ How do I deal with memory leaks? Instead of gushing about how great smart pointers are, let Sutter and Alexandrescu do the talking by inviting your audience to read item 13 of C++ Coding Standards. Show them Meyers example of how failing to use a smart pointer can lead to bugs by showing them item 13 of Effective C++, 3rd Edition, and then point out that Meyers' fixed example of using std::auto_ptr is soon to be outdated by std::unique_ptr. Reason that the inclusion of std::unique_ptr in the next version of the C++ standard indicates that the general C++ community is moving towards the use of smart pointers precisely because of the benefits described by Stroustrup, Meyers, Sutter and Alexandrescu.

---

You are right and I just did do it the constructive/technical way.
I was just curious to see what would happen when I said I had to stuff it down their throat. Learning to separate emotions from your programming style is a very valuable technique to learn for every software engineer and it is great to see how we can get emotional about it. Maybe even more valuable than knowing everything about C++

Sorry to hijack the thread but my question is still in the same area. While I agree on the part that we should design our code better with bunch of helpful libraries and standards, what about the personal programming style of each programmer itself? Eg. indent style, vertical alignment, tabs vs spaces, naming convention, etc? Especially about whitespaces (ie. indent, tabs, spaces) considering C++ doesn't have significant whitespace rules like Phyton. It is not only because it is a personal thing that can get the programmer to be very sentimental over it. But it also enhances the readability of the said programmer, and in result can get him to understand the code faster. For instance I usually use the Allman indent style and I see that I am having a hard time reading the more popular K&R style. But then again, if you are working with lots of programmers, a source code with different styles in it is so wrong IMHO.

Styles tend to be like holy war. Nevertheless, when working with several programmers, it is usually best to agree on a common style. That's usually company policy.