31–40 of 150 posts
If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again.
From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)
As a side note: if(b->qid.path==a->qid.path) is interesting. This is not how you compare strings in C. So it is either a bug or dirstat() needs to guarantee that different results pointing to the same file always share the path string.
Qid is a structure containing path and vers fields:
path is guaranteed to be unique among all path names cur-
rently on the file server, and vers changes each time the
file is modified. The path is a long long (64 bits, vlong)
and the vers is an unsigned long (32 bits, ulong). Thus, if
two files have the same type, dev, and qid they are the same
file.
As a side note: if(b->qid.path==a->qid.path) is interesting. This is not how you compare strings in C. So it is either a bug or dirstat() needs to guarantee that different results pointing to the same file always share the path string.
Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)
And what's the alternative for if(A && B){ x(); }else{ y(); }? Seems very easy to shoot yourself in the foot with this approach.
if (one) {
if (two)
if (three)
if (soon) {
stuff
}} else {
else stuff
}
Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)
https://feralbynight.googlecode.com/files/FeralbyNightv3_2_b...
Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)
Thats hideous? I see worse code everyday.
There's worse songs than "Who Let the Dogs Out" but it's still a really bad song.
Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)
Yes, of course, I know the argument: a one-line bracketless "if" can set-up a future developer for failure if they need to add an item to the conditional block. And if they for some reason decide not to read the actual conditional. And if they don't test it.
And I don't hate code that uses braces even when they're not strictly needed, but I personally prefer to omit them. And my feeling is that the dogma around braceless-ifs is a little overblown.
Of course when working on a team that has adopted a no-braceless-if policy, I conform. Having consistent code is way, way more important than somebodies own favorite bracing style.
One downside to non-braced conditionals is that a semicolon accidentally placed after the conditional will cause the block to always run, e.g.: if (null != foo); bar(); This is valid code in C and Java, and bar() will always run in this case. Having seen people waste hours on such a semicolon, I always use braces, even in one-liners, because I never know when someone is going to break it out into multiple lines later…
if (null != foo);
{
bar();
}