Talk:Style Guidelines: Difference between revisions
Intended for new code |
Clonk-Karl (talk | contribs) Commented guidelines |
||
Line 14: | Line 14: | ||
Opinions: | Opinions: | ||
* Use anonymous namespaces instead of static: '''In favor:''' ck | * Use anonymous namespaces instead of static: '''In favor:''' ck, Isilkor; '''Against:''' Günther, PeterW | ||
* Doxygen comments: '''In favor:'''; '''Against:''' Günther, PeterW | * Doxygen comments: '''In favor:'''; '''Against:''' Günther, PeterW | ||
The document should describe reality, not wishful thinking. Where reality is inconsistent, the document can describe which of several options is preferred, but it shouldn't contain anything that's not already in somewhat widespread use. That would mean changing the coding style, and that's not the job of a coding style document. --[[User:Günther|Günther]] 16:41, 4 August 2009 (UTC) | The document should describe reality, not wishful thinking. Where reality is inconsistent, the document can describe which of several options is preferred, but it shouldn't contain anything that's not already in somewhat widespread use. That would mean changing the coding style, and that's not the job of a coding style document. --[[User:Günther|Günther]] 16:41, 4 August 2009 (UTC) | ||
: The document is intended to describe guidelines for new code, and not the legacy code that's all over the place anyway. While it's probably preferable to change old code if you do work in the vicinity, I certainly don't expect the code to be changed/reformatted on its own. --[[User:Isilkor|Isilkor]] 17:35, 4 August 2009 (UTC) | : The document is intended to describe guidelines for new code, and not the legacy code that's all over the place anyway. While it's probably preferable to change old code if you do work in the vicinity, I certainly don't expect the code to be changed/reformatted on its own. --[[User:Isilkor|Isilkor]] 17:35, 4 August 2009 (UTC) | ||
I would not restrict the order of case labels in a switch. But if we do, then I agree with PeterW that they should be ordered by numeric value (which, for enumeration values, is mostly the same as the order the enumerators are defined). Maybe we also want to note that for commenting out code, #if 0 is preferred. I am generally okay with these guidelines, though I'm likely to have problems with a few I'm not used to, especially the pointer asterisk position and the space following if/while/for. When I am writing code then I am paying attention to the code and not the style, and I often fall back to my own style without even noticing. So please don't punch me if I check in code that doesn't strictly obey the guidelines. --[[User:Clonk-Karl|Clonk-Karl]] 00:23, 5 August 2009 (UTC) |
Revision as of 00:23, 5 August 2009
Responses so far: Günther:
- local headers before system headers
- don't forbid public data members
- <!Guenther> Demanding Doygen comments is also a very radical change
- <!Guenther> Doxygen is only really usefull if you are generating API docs that are intended to be read without looking at the source code
- <!Guenther> That's not a use case for us: our API is C4Script, not some C++ API
PeterW:
- order switch members by numeric value
Afterthoughts Isilkor:
- Use forward declarations instead of including the header inside other headers, if possible.
Opinions:
- Use anonymous namespaces instead of static: In favor: ck, Isilkor; Against: Günther, PeterW
- Doxygen comments: In favor:; Against: Günther, PeterW
The document should describe reality, not wishful thinking. Where reality is inconsistent, the document can describe which of several options is preferred, but it shouldn't contain anything that's not already in somewhat widespread use. That would mean changing the coding style, and that's not the job of a coding style document. --Günther 16:41, 4 August 2009 (UTC)
- The document is intended to describe guidelines for new code, and not the legacy code that's all over the place anyway. While it's probably preferable to change old code if you do work in the vicinity, I certainly don't expect the code to be changed/reformatted on its own. --Isilkor 17:35, 4 August 2009 (UTC)
I would not restrict the order of case labels in a switch. But if we do, then I agree with PeterW that they should be ordered by numeric value (which, for enumeration values, is mostly the same as the order the enumerators are defined). Maybe we also want to note that for commenting out code, #if 0 is preferred. I am generally okay with these guidelines, though I'm likely to have problems with a few I'm not used to, especially the pointer asterisk position and the space following if/while/for. When I am writing code then I am paying attention to the code and not the style, and I often fall back to my own style without even noticing. So please don't punch me if I check in code that doesn't strictly obey the guidelines. --Clonk-Karl 00:23, 5 August 2009 (UTC)