Funny C Rules (And Low-Level Languages in general)

[jitspoe]

I generally return true on success for most functions, unless they can return more than 2 values. The compare functions return 0 for "true" or "equal" because they can return both positive and negative values, which matters when used for sorting. To reduce confusion, I've made my own functions for simple equality checks, like Q_streq(), so you don't have confusing code like "if (!strcmp(...".

[Baker]

[Spike]

0 for sucess makes sense in that you only have one success code, and multiple reasons for failure.
the alternative is the unix way, where <0 are errors, and >=0 are success codes. which is fine until you have 32bit+ results.
really its the difiference between a boolean and an (oob)enum. if the return value is defined as a bool of some kind, then its true for success. otherwise it should be 0 for success (as opposed to false).
and if its HRESULTS, use the FAILED or SUCCEEDED macros to provide the appropriate comparisons (note that these are consistant with the unix way).

VectorCopy is absurd. fix it BEFORE your engine becomes a sprawling monstrosity...

[mankrip]

My interpolation macros uses (previous_src, dest, next_src), because that's what makes more sense for me.

Also, trying to guess the order of any functions is bad. I always take a look at the function declaration if I don't know/remember the order.

And imo, error codes are also bad. Errors should be treated internally, instead of hoping that the functions that called the functions that generated the errors will take care of them.
Btw, this is why I dislike the conventional return values used by stuff like strcmp. When using strcmp, the coder is essentially asking "does those strings match?", and a no is a valid answer for such a question, so in cases like this it makes no sense to assign the return values as if they were error codes.
To me, a "no" doesn't mean that the comparison performed by strcmp failed. A real failure would be if strcmp couldn't determine whether does the strings match or not.

[Baker]

[jitspoe]

I guess the parameter order thing is all a matter of perspective. I always thought it made sense reading left to right, like with VectorCopy(A, B); I'm starting with A, and copying it to B.

Consts and better parameter names (like VectorCopy(in, out)) can help with this confusion.

It wasn't until I read some posts here with "A = B;" that it even crossed my mind that it could make sense for the destination to be on the left. I always thought the leftmost parameter being the output was necessary for functions like sprintf() where the parameters were variable, so you couldn't have the output parameter be at the end, and some other functions just followed that to try to be consistent, not because it was intuitive.

[Baker]

I had never consciously thought about A = B either, which is a winner. That provides some extra clarity (for what I always believed).

I had become accustomed to memcpy and strcpy, therefore VectorCopy messed with my head. Generally, when I write functions, any function that alters something I tend to have it as the first parameter (the operand).

[Spike]

mathematically, assignments commonly store to the righthand side. even quake's opcodes store to the right (yup, qcc interprets assignments the other way around from other 2-argument instructions).
really, consistancy is important.
even libc is inconsistant:
fputs(source, dest);
fprintf(dest, source);
personally I favour the object being updated as the first argument, because with stuff like fprintf, its easier to be consistant that way.
strlcpy(dest, source, destpart2); is annoying too.

[Baker]

Not really on-topic but ...I switched from Courier to the Liberation Mono font (which is fixed width). I get 15% more vertical lines. I can't tell any difference other than seeing more. I think the difference is mainly overhang/descent whatever you like to call what lowercase g, y, j do.

[Baker]

[dimman]

A couple of notes:
12) Variables declared static or global variables have static storage duration and are initialized to zero
13) Due note that you cannot do sizeof int for instance, or any type, you do need parenthesis for those: sizeof(int)

[Baker]

[Baker]

[Baker]

We think of comments as being ignored. This isn't actually true.

They are interpreted as whitespace.

int x/*hello*/y = 5; // Error. If the comments were ignored, this line would be int xy=5;

[Baker]