9
\$\begingroup\$

I often see C and C++ questions where the coding style in some of the answers is different from the one in the question. While some languages have guidelines concerning the coding style (Java, Python, etc...), some don't have any strict guidelines concerning the coding style (C, C++, etc...), therefore, several coding styles may differ and none of them will be "better" (unless there is a good reason to use a coding style rather than another one, e.g. consistency with a specific library coding style).

When a question is posted with a valid and consistent coding style, should we try to respect this coding style in the answer? I often see answers that propose snake_case functions to questions where a consistent camelCase is used for function names, or answers where the indentation style does not match the one used in the question.

I think we should somehow encourage Code Review users to be as consistent as possible with the coding style used in a question when they answer it. It would also probably be easier for the asker to understand answers written with their coding style.

\$\endgroup\$
7
\$\begingroup\$

You're mostly right that maintaining the original style for C/C++ code is generally the nice thing to do. At the same time, I'd rather not make a fuss about it.

Some languages, like French, are prescriptivist. The Académie Française makes the rules, and people mostly follow them.

Other languages, like English, grow organically. There are many dialects and accents, and while some are closer to "standard" English than others, the regionalisms coexist reasonably well. When an American and an Indian converse in English, each speaker generally speaks his/her own dialect, and the listener makes some effort to understand. As long as the dialect is not too out of the ordinary, the adjustment is no big deal. Actually, it would be more awkward to point out distinguishing features of your interlocutor's dialect than to just pretend that you both speak the same language.

So, Go and Python have official style guides. C/C++ don't. The slightest mention of brace styles for C/C++ risks sparking a flame war, and I really don't want any of that on Code Review. There are so many more substantive issues that should be addressed in most questions that superficial issues don't even deserve a mention.

While it would be more polite to make an effort to keep the same style as the original code, I don't think it makes much practical difference either way. The code in an review is usually just an illustration, and is of secondary importance to the advice.

\$\endgroup\$
  • \$\begingroup\$ I wouldn't want to enforce it as a rule or anything, I agree that it is mostly begin polite. It could be something to add to a blog post about "how to write a good review" though if such a post comes up. \$\endgroup\$ – Morwenn May 12 '14 at 9:28
  • 3
    \$\begingroup\$ I'd prefer not to mention anything at all on the matter, for fear of painting Code Review as a community that concerns itself with unproductive advice on superficial issues. \$\endgroup\$ – 200_success May 12 '14 at 9:39
4
\$\begingroup\$

Additionally to @200_success' answer I want to mention that in some languages where there are more or less official conventions (C#, Java, Python, ...), the answer should follow that style, even if the question follows a different one.

Prominent example here would be Java and C# braces. I have already seen many questions, where C# code was written with Java conventions (camelCase methods and properties, egyptian braces) and the other way round.

In this case it is IMO always better to follow the official standard in the answer, at least not to upset any hardliners (read: to prevent a flamewar), but in the best case, to educate the OP.

\$\endgroup\$
  • \$\begingroup\$ That's why I mentioned that my question did not concern such languages in my first paragraph :p \$\endgroup\$ – Morwenn May 12 '14 at 11:40
  • \$\begingroup\$ @Morwenn I still wanted to explicitly make that clear:) \$\endgroup\$ – Vogel612 May 12 '14 at 14:46
-1
\$\begingroup\$

Who cares about the style in the answer to a question, honestly. If someone posts an answer with snake_case in their answer, will it really alter the context of their solution? No. Will indentation alter it? No. Unless you copy & paste all of your answers right into your projects (which would be insane), why would it matter?

If an answer provides a solution, OP may simply take that answer and change the style to their liking. Plain and simple. If they're too lazy to alter the answer and simply want to post it into their project... well, no more can be said.

\$\endgroup\$
  • \$\begingroup\$ Who cares? Many people from what I can see. \$\endgroup\$ – Morwenn May 25 '14 at 15:58
  • \$\begingroup\$ And the question is not strictly about case, but more generally about consistency between the question and the answer. \$\endgroup\$ – Morwenn May 25 '14 at 15:58
  • \$\begingroup\$ @Morwenn So you give me a link of an article about the dispute in the community. It's fine. But it shouldn't affect the answers. Why would there a need to be consistency if the answer has a viable solution? The OP can simply alter it to their own style. If anything, it provides an benefit of exposing various styles. By the way, no need to post two comments 1 minute apart from each other. You may edit the comment. \$\endgroup\$ – B.K. May 25 '14 at 16:13
  • \$\begingroup\$ Probably because Code Review tries to help people writing good and maintainable code and that consistency is one of the keys to write maintainable code. \$\endgroup\$ – Morwenn May 25 '14 at 16:24
  • \$\begingroup\$ @Morwenn I don't argue the fact that consistency should be made in the production code, but should the style of OP's casing, for example, influence the input from others? If anything, it removes the possibility of diversity. There's no major harm in non-radical style. Perhaps OP only knows one style, or didn't know about another possibility. An introduction of another style may actually benefit them. \$\endgroup\$ – B.K. May 25 '14 at 16:39
  • \$\begingroup\$ It's true that I did not consider it under that angle. I probably always assumed that we were pursuing some kind of goal to review code that could also be good production code (you know, the "real code that you wrote or that you maintain" requirement in the code you can post here). I would think that anybody that has read some tutorials has already encountered different coding styles though. \$\endgroup\$ – Morwenn May 25 '14 at 16:58
  • 1
    \$\begingroup\$ @Morwenn Wouldn't that be great, but as you know, that's not always the case. I do like your points though. \$\endgroup\$ – B.K. May 25 '14 at 18:07
  • 1
    \$\begingroup\$ Following naming conventions can be extremely important in some languages: "The naming of your functions is particularly important, since its effects extend beyond your own code. You've just indicated that you will burden your future colleagues with non-standard naming." \$\endgroup\$ – 200_success May 26 '14 at 19:38
  • \$\begingroup\$ @200_success Totally. 100% accurate indication. \$\endgroup\$ – B.K. May 27 '14 at 0:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .