Replies

Not if you want to keep your job.

Not necessarily true. I have seen at the bottom of some small functions where there are multiple failure paths that have the same cleanup needs, like releasing the memory for BSTRs and such. It is pretty rare, but I have seen some real accomplished and talented programmers use it.

But it definitely is not the way to set up any kind of structure, that is for sure.

C is the only thing in the computer world that I truly loved without reservation.

Me too.

I've never understood why "goto" is not preferred to getting out of deeply nested 'if thens' and 'do loops' over repeating and executing a lot of really unnecessary code.

[...there is a "goto" in C.]

Not if you want to keep your job.

I've used "goto" in C/C++ quite a few times, and I still have a job. ;-)

Actually, while it's a good rule of thumb to avoid "goto" whenever reasonably possible (and most times it *is* reasonably possible) there are always a few times when avoiding one just for the sake of obsessive-compulsion can make the code a lot uglier than it would be otherwise.

Some of the more obvious examples are error-handling (like you're 12 levels deep in control structures and it's time to bail the hell out because of a major failure), or similar special-case scenarios.

In many of those situations, all the goto-less alternatives are even uglier than the more simple and obvious "goto CLEANUP_AND_RETURN;" option.

C is the only thing in the computer world that I truly loved without reservation.

OK, I liked C too, but IMHO for writing large complex programs correctly used C++, Java, or C# in particular has it beat by a long way.

My wife got tired of me hanging round the house a little while ago so I went out and got a job as development manager in a small software house. I can't say that the director who interviewed me didn't give me fair warning once I'd persuaded him that I wasn't after his job. What these guys have done (something like 40 developers) is written millions of lines of C, but using C++ syntax so they are under the illusion that they are writing in C++. #defines everywhere instead of inlines, no polymorphism at all, copious use of memset(0,sizeof) on pointers to class instances (which would of course break if they did go polymorphic), copy-and-paste used *every time* already developed stuff was needed elsewhere, presentation/business/data logic hopelessly mired in a single spaghetti tier. But hey! They'd got coding standards, "no gotos, lots of variable naming rules and only one return per function" (that last return rule some people like, but IMHO creates really ugly code). Some serious re-education is going on which is actually an interesting challenge. I'm trying to get the message through to the team-leaders that obeying a few rules about variable names and in-function code-structure doesn't make your code good.