Talk:Style Guidelines: Difference between revisions

Isilkor (talk | contribs)
No edit summary
Isilkor (talk | contribs)
Intended for new code
Line 16: Line 16:
* Use anonymous namespaces instead of static: '''In favor:''' ck?, Isilkor; '''Against:''' Günther, PeterW
* 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 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)

Revision as of 17:35, 4 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)