>>67
No, it's because the ancient compiler that K&R used had a bug in it where it couldn't parse the opening brace of a function unless it was after a newline. Why would the lack of nested functions matter to indentation style? Java in particular allows nested classes and the official Java style guide suggests putting the opening brace on the same line.
Here's a relevant question for the
/prog/ crowd: Do you block and/or indent semantically relevant code blocks, such as mutex locking or glBegin/End?
void PaintRect(void) {
glBegin(GL_TRIANGLE_STRIP); {
glVertex2f(0,0);
glVertex2f(0,1);
glVertex2f(1,0);
glVertex2f(0,1);
} glEnd();
}
void DecRefCount(Object* obj) {
pthread_mutex_lock(&mutex); {
if (!--obj->refCount) {
obj->destroy_fn(obj);
free(obj);
}
} pthread_mutex_unlock(&mutex);
}
It has the same advantage as 1TBS in that code merging by revision control systems is much less likely to produce bad code (you really can't resolve the conflict incorrectly, whereas without the indent, if you aren't paying close enough attention you might accidentally put a critical statement on the wrong side of the mutex, causing a race condition or deadlock). Plus you can't really forget the close/unlock as you're typing when you do it this way (if you're not in the habit of writing open/close at the same time). Lots of OpenGL examples use this style.
However it might be misleading. For instance I would expect to be able to break or return out of a nested scope (since closing the scope usually doesn't have an effect), whereas you really can't do that here. I guess you have to remember to check whether closing braces have a closing statement, whereas I'd be much more hesitant to skip the rest of the function when it's flat. Maybe that's just because my eyes are used to skipping over closing braces, since aside from do {} while, there's never anything after them. Another downside is you have to forward declare variables outside the scope if you want to get their values after unlocking (you could do the indent without the block, but that's even more misleading). And another downside is, where do you draw the line as to what you indent or don't indent? Do you indent temporary variables that need to be destroyed, for instance?
void doSomething() {
SomeObj temp;
SomeObjInit(&temp); {
// do some shit
} SomeObjDestroy(&temp);
}
I think despite these disadvantages I'm still considering using this style at least for mutex locking in my own projects. Of course if you're in Sepples you should just use RAII. I'm rambling at this point. What do you think?