Code Policy

[Peter]

link=topic=21350.msg251113#msg251113 date=1251350543]

Code:

if (strcmp (szPlayerChatMsg1, szPlayerChatMsg2))
{
    doSomething ();
}

I like to do it that way.

So do I.

[Pugwipe]

My personal preference is closest to the K&R style nowadays, with spacing like in [Griffin]'s example:

Code:

public SomeCallback ()
{ // Opening function brace on a new line
    for (new i = 0; i < SLOTS; i++) { // Opening brace on the same line in control structures
        if (!IsPlayerConnected (i)) continue; // No braces around single statements such as these

        SendClientMessage (i, COLOR_WHITE, "Hello there!");
        DoSomeMoreStuff ();
    }

    // Note the use of empty lines for clarity
    return 1;
}

I'm fine with pretty much anything though, as long as everybody follows the same conventions.

[Felle]

I prefer something like this:

Code:

public bla()
{
    if (bla == 1) {
        callFunction();
    }
}
   

... which is the same as Pugwipe's example apart from that I don't use spaces before the parenthesis when calling functions.

Any way is fine for me (I'll adjust without bigger issues), and I do agree that deciding upon one way is a good idea.

[Fireburn]

We have created some guidelines based on the posted opinions. If you have any problems with this Policy, please post within 3 days.
http://trac.sa-mp.nl/lvp/wiki/CodePolicy

We'll create a topic about documentation tommorow, where we will go about how we documentate in code / trac.

[Jay]

[23:23:39] <@Jay> Instead of n for number, wouldn't i make more sense, for integer?
<&Fireburn> I would think i is more easy too

[]...

[23:24:40] <@Jay> And imo using a for array is a little over the top
<@Jay> It should depend on what each value in the array is worth, e.g, if it was numbers, iArray, or strings, szArray

[]...

<@Jay> Yes but it contains an integer. Instead of naming every array aPlayerBank, it would be much easier, and clearer to understand, to name them after the data they're storing
[23:29:44] <&Fireburn> I agree with that
[23:29:47] <&Fireburn> Wesley doesn't

[Pugwipe]

[23:23:39] <@Jay> Instead of n for number, wouldn't i make more sense, for integer?
<&Fireburn> I would think i is more easy too

Totally agreed. 'Integer' is much more specific, as numbers aren't necessarily integers.

[Wesley]

We'll be using 'n', and not 'i', this is because pawn doesn't know a difference between an unsigned and a signed integer, it knows only one datatype, being 4 bytes.

An array will be indicated by an 'a', and not the type of its content, this is mainly because an array can contain different types by using an enum.

[Pugwipe]

We'll be using 'n', and not 'i', this is because pawn doesn't know a difference between an unsigned and a signed integer, it knows only one datatype, being 4 bytes.

That's some of the biggest bs I've ever heard; signed or unsigned, it's still an integer. Going by your logic, floating point numbers should also be prefixed with 'n', they're numbers too, right?

[Peter]

I'd say you use "n" rather than "i", for the very simple reason there's a major advantage of doing so: iterators. There's a reason "i" is always used in for loops...

Use the "i"-prefix for iterators and indexes; iLoop, i and iPlayerId in loops.
Use the "n"-prefix for numbers: nBankValue, nPlayerFlags and nPlayerId in functions and/or methods.

I kindof agree with the datatype argument; in normal hungarian notation there's a difference between four major types;

[table]
[tr][td]Size[/td][td]unsigned[/td][td]signed[/td][/tr]
[tr][td]1 byte (char)[/td][td]uc[/td][td]c[/td][/tr]
[tr][td]2 bytes (short)[/td][td]us[/td][td]s[/td][/tr]
[tr][td]4 bytes (int)[/td][td]ui[/td][td]i[/td][/tr]
[tr][td]8 bytes (long)[/td][td]ul[/td][td]l[/td][/tr]
[/table]

Pawn always is 32-bits. While it may seem obvious to use "i", seeing the Pawn integers are signed as well, the fact that even arrays ("new variable[256]" actually is 1 KB in size) are integers makes it confusing. Everything would be "i". Therefore I'd strongly suggest to differentiate between "i" (indexes/iterators) and "n" (numeric values). After all, floats are nothing else than casted integers in pawn either way (then again, strictly seen they always are).

[Fireburn]

Thanks everyone for all reactions, based on everything said here we made this policy, which is final from now on.

http://trac.sa-mp.nl/lvp/wiki/CodePolicy