Tuesday 18 October 2005 — This is more than 19 years old. Be careful.
I know this is a small thing, but it snagged my brain this morning. I hate the C standard library function wcscmp. First, because the name is so crappy (it stands roughly for Wide Character String CoMPare). Second, because although it returns a true comparison (which of the two arguments is greater), it’s almost always used to compare for equality, and therefore has to be negated. It returns zero if the strings are equal, so you end up writing this:
if (!wcscmp(s1, s2)) {
// Do something if s1 and s2 are equal...
}
Or worse, you want to know if they are not equal, so you leave off the negation. When I see wcscmp, I think, “we’re comparing to see if the strings are the same”, but then I have to carefully navigate that negation to get the sense correct.
If we’re not going to have a real string class with an equality operator, I much prefer to have a StrEqual function:
inline bool
StrEqual(const wchar_t * s1, const wchar_t * s2)
{
return !wcscmp(s1, s2);
}
Then I can write what I mean. But others feel that at least wcscmp is standard. I’ll take readable and straightforward over standardized obfuscation any day.
Comments
if ( !StrEqual( sname1, sname2 ) )
{
// do something if not equal
}
if(0 == strcmp(str1, str2))
rather than using !strcmp() - but I avoid having to write C if at all possible.
I'm inclined to think that if (wcscmp(s1,s2) == 0) isn't anywhere near as obfuscated, even though it's the same thing, because you're not mentally expecting the function to return "are they equal or not", you're expecting it to return a particular value or not. That that value *happens* to also be the Boolean false is a coincidence.
There's no way I'm writing "0 == function()" instead of "function() == 0". I understand the logic of "0 == foo" (it prevents an accidental assignment instead of comparison), but "function() = 0" won't compile, so we don't have to prevent against it by twisting things backwards!
Yuk.
For example:
if ( FunkyFunctionToDoStuff( variable1, variable2, variable3 ) == 0 )
is a lot harder to scan over in the code than this:
if ( 0 == FunkyFunctionToDoStuff( variable1, variable2, variable3 ) )
To get the gist of the first one, you need to read the entire line, for the second one, you only need to read 10 or so characters (assuming you don't have a lot of "FunkyFunction"s :)
I used to work with someone who used to switch *all* of his logic around to put the variable at the end of the expression. He'd write code like this:
if ((0 < foo) && (10 > foo))
rather than
if ((foo > 0) && (foo < 10))
As far as (func() == 0) vs. (!func()), I prefer the first. Mostly because I've been mostly working in languages that don't allow int and bool(ean) to be treated as the same thing.
if ( FunkyFunctionToDoStuff( variable1, variable2, variable3 ) == 0 )
different from:
if ( FunkyFunctionToDoStuff( variable1, variable2, variable3 ) > 0 )
Seems that you ought to reverse them both if you want to see the operator earlier in the expression.
Regarding the (0 == func()) syntax. Code isn't just written to be compiled, it's written to be read. To me, the reverse comparison looks stylistically "wrong". It's entirely equivalent to the compiler but I prefer the classic comparison syntax. It's no different than brace style or any other stylistic code layout issue.
To avoid "layout style" wars, any reasonably large project should adopt a coding style guide as early as possible. Not to stifle creativity -- it's to make sure that everyone on the project can quickly and accurately read one another's code without tripping over stylistic differences.
And yes, at every job I've worked, we've had coding standards which everyone was required to follow. it's definitely a good idea, especially to reign in some of the more messy coders.
There are a lot of little decisions for coding style:brace style, indentation, paces vs. tabs, comments, naming conventions, etc. They're subjective but not unimportant. It's highly unlikely that you'll get unanimity on "one true style" but developers should be flexible enough to adapt. On a recent project one of the developers ranted and railed about the choice of brace style. He insisted that his style was more readable and refused to change. Yeah, he was a real team player ;-) But the decision wasn't made arbitrarily. We were adopting an existing style guide and there was a large existing body of code that was already written in that style.
Add a comment: