goto instruction

[blobmiester]

Simply don't use returns everywhere in a function.

From what I can see, your primary case for a return in the middle of a function is in case of an error. Check all parameters for errors before processing anything. and maybe a:

Code: Select all

if (valid) { ... }

or similar.

Or better, you can have an inline function which will process your allocated variables:

Code: Select all

void foo(...)
{
    void* buffer = NULL;
    buffer = malloc(1337);
    process(buffer);
    free(buffer);
}

Then again, I'm not much of a C guru, as I'm more used to C++ and using shared_ptr / auto_ptr to handle freeing with their destructor.

On a side note, you can remove the if (x != NULL) checks before free calling free(x). The standard dictates that free performs no operation if x is null.

The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if
the argument does not match a pointer earlier returned by a memory management
function, or if the space has been deallocated by a call to free or realloc, the
behavior is undefined.

[Solar]

I was speaking in a more generic sense. It's the basic attitude that "I shouldn't code for what the computer does easily, I should code for what a human can read." That's not "good programming".

And I claim the opposite - that this is the basis of good programming. Making the code also efficient is the basis of excellent programming.

But it's a (somewhat sad) fact that, most of the time, readability trumps efficiency, and also most of the time, code claimed to be "efficient" isn't.

I claim that you are under the misimpression that C is a structured language.

I claim that, if you cannot make the code you're writing "structured" no matter the language, you shouldn't call yourself a programmer.

[Solar]

And I fervently claim it SHOULD always be used to leave a function early. I find it absolutely confusing to see functions with several returns all over the place, because whenever later you need to add cleanup code to your function, you have to look at all of these returns.

{some really braindead code following}

Sancho, from your initial post I gathered you do this for a living. I strongly suggest you get a basic course in how-to-code-properly, ask your boss to have some senior programmer give you regular code reviews, or please, for the love of what's holy to you, stick to VisualBasic 6, because that's what you're coding.

Then again, at this point I call "hoax" on your whole thread. No-one who's doing this professionally can write that bad.

Then again, given things I've seen already, maybe this is possible. In that case, make sure none of your co-workers ever find out where you live.

Seriously, this is ridiculous. Not only your use of goto, but just about everything in that code sample of yours is as bad as it could get.

[gerryg400]

Solar, I fear (really, actually, fear) that this may be a pointless argument.

[sancho1980]

Seriously, this is ridiculous. Not only your use of goto, but just about everything in that code sample of yours is as bad as it could get.

May I ask you to have a look at my small os project at

http://code.google.com/p/mycrokernel/

It's not too big, and I'm advancing slowly as I'm doing this next to my job and a lot of other things, but it's a toy OS that boots the bare wire all by itself and implements a microkernel architecture with Virtual Time Round Robin scheduling. The assembly part is written with HLA (High Level Assembly), the rest is done in C. It doesn't do too much, except provide the foundation for pocess scheduling and an interface for a few system calls. Then it hooks up a few rudimentary processes (TTY and shell). Tell me if you can get so far with Visual Basic style programming.

[Solar]

You intentionally don't get the point. End of discussion.

[Chandra]

Solar, I fear (really, actually, fear) that this may be a pointless argument.

And I fear that this thread is going to hurt someone. Please stop it before it gets wilder.

[sancho1980]

Simply don't use returns everywhere in a function.From what I can see, your primary case for a return in the middle of a function is in case of an error.

Or if I'm done early with my function.

Check all parameters for errors before processing anything.

That's right, but not enough. Errors might also occur when calling other functions in the course of your function.

If you take the time to look at my little project, you will see that nearly all functions take also an error parameter:

Code: Select all

void function (err_t *error)
{
  //some code
finish:
  return;
}

then I have a macro (terror for Test Error), like so:

Code: Select all

terror(x) x; if ((*error) != 0) goto finish;

And this all combines to something like

Code: Select all

void function (err_t *error)
{
  dynamic_t *myVar = NULL;
  //some code
  terror(otherFunction(error))
  //some code
finish:
  if (myVar != NULL) {
    free(myVar);
  }
  return;
}

On a side note, you can remove the if (x != NULL) checks before free calling free(x). The standard dictates that free performs no operation if x is null.

I know

[quok]

Solar, I fear (really, actually, fear) that this may be a pointless argument.

And I fear that this thread is going to hurt someone. Please stop it before it gets wilder.

I agree, let's stop right now.