In rP19667#21440, @leper wrote:

Fix the whitespace in lib thing.

https://trac.wildfiregames.com/wiki/Coding_Conventions

Exception: Code in source/lib/ omits the space before the '(' in statements like "if(...)", "while(...)", etc.

It it ambiguous because it can be read both as a recommendation and as a annulment of the above rule, which would make lib/ an unlegislated area (which it already appears to be).
I've always read it as "Exception: lib/ is broken`.

213 if ( vs 1510 if ( in lib/. I'd rather make a commit changing those 213 occurances than making a beyond pointless commit 'fixing' one instance that makes it further inconsistent in the same file.

The other comment in the coding conventions about lib/ that says that it tends to use something sould be replaced with an actual rule too.

Exception: source/lib/ and source/simulation2/ and source/scriptinterface/ tend to prefer std::[w]string instead.

Having two different coding conventions for one codebase is terrible, even if that is contained in a different subdirectory.

In rP19667#21448, @elexis wrote:

Exception: source/lib/ and source/simulation2/ and source/scriptinterface/ tend to prefer std::[w]string instead.

Having two different coding conventions for one codebase is terrible, even if that is contained in a different subdirectory.

It's true for indentation, but not for technologies, because lib means, that a code could be used somewhere else too (and it was used AFAIK, but I'm not sure about now). So the rule about std::[w]string is correct.

In rP19667#21449, @vladislavbelov wrote:

In rP19667#21448, @elexis wrote:

Exception: source/lib/ and source/simulation2/ and source/scriptinterface/ tend to prefer std::[w]string instead.

Having two different coding conventions for one codebase is terrible, even if that is contained in a different subdirectory.

It's true for indentation, but not for technologies, because lib means, that a code could be used somewhere else too (and it was used AFAIK, but I'm not sure about now). So the rule about std::[w]string is correct.

We could also remove the CStr recommendation too, since it isn't even followed for our source. Noone had raised a concern when we committed a std::string and it was even advised to keep the same style in the file.

https://trac.wildfiregames.com/wiki/Coding_Conventions

Exception: Code in source/lib/ omits the space before the '(' in statements like "if(...)", "while(...)", etc.

It it ambiguous because it can be read both as a recommendation and as a annulment of the above rule, which would make lib/ an unlegislated area (which it already appears to be).

I'm not sure what is ambiguous there. "Do foo. Exept for bar, then doo baz."

213 if ( vs 1510 if ( in lib/. I'd rather make a commit changing those 213 occurances than making a beyond pointless commit 'fixing' one instance that makes it further inconsistent in the same file.

I'm not sure why you count the same thing twice, but I'll assume that one of them should not have a space. Yes, having that difference in coding style is bad, but we should not claim that anyone should even follow the coding conventions when we ourselves can't do so.

The other comment in the coding conventions about lib/ that says that it tends to use something sould be replaced with an actual rule too.

Exception: source/lib/ and source/simulation2/ and source/scriptinterface/ tend to prefer std::[w]string instead.

Because CStr is not in lib/ (and GPL at that). But CStr is a rather thin wrapper with a few convenience functions around tstring, so that one doesn't really matter.

Having two different coding conventions for one codebase is terrible, even if that is contained in a different subdirectory.

We could change it if we really wanted, but that should be discussed first. Not something to be decided once we are at a point where it is too late.

Also you forgot to fix the other occurences of if ( in rP19684.