mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-06-25 12:06:36 +02:00
Bram Matthys
98 lines
4.1 KiB
Plaintext
98 lines
4.1 KiB
Plaintext
|
|
Some minor rules about patches & modifications to UnrealIRCd
|
|
|
|
1. When making a change, always add a small description in Changes, in the
|
|
BOTTOM. Be sure to mention the bugid# (or muliple id's) if you are fixing
|
|
a bug from a bugtracker, and be sure to credit the reporter. Use:
|
|
'Fixed blahblahblah, reported by Blah (#0001234).'
|
|
Or, for example, for features:
|
|
'Added support for blahbalbvdshd, suggested by Blah (#0001235).'
|
|
Or something similar ;)
|
|
|
|
2. If new files are made, it must contain proper copyright headers,
|
|
and a $Id$ somewhere.
|
|
|
|
3. /*
|
|
* These kind of comments
|
|
*/
|
|
|
|
NOT
|
|
|
|
// These kind of comments
|
|
|
|
4. if (something == 1)
|
|
{
|
|
moo; /* comment */
|
|
/* This does what what what */
|
|
cow(go(moo));
|
|
}
|
|
|
|
NOT
|
|
|
|
if (something == 1) {
|
|
}
|
|
|
|
5. Do not touch version.c.SH or version.h, unless you are a head coder
|
|
if you need a credit in, contact us
|
|
|
|
6. Patches are submitted to coders@lists.unrealircd.org,
|
|
using "cvs diff -u > patchname". A submision must contain description of
|
|
what it does, etc.
|
|
|
|
7. Protocol changes must be discussed before making patches for it.
|
|
|
|
8. We do NOT rip people off. If we use other people's code, it MUST be
|
|
properly credited.
|
|
|
|
9. We generally use tabsize 4 and 8. In any case, use tabs and NOT spaces.
|
|
Some code is old and horrible and has a mix of tabs and spaces used for
|
|
spacing, that's something we do not want to have ;)
|
|
|
|
10. Be careful about overflows. As you know a line from a user can never be longer
|
|
than 511 (510?) characters, sometimes you can use this knowledge to your
|
|
advantage. Whenever it's not safe or when you don't know what input size you
|
|
can expect, use strlcpy instead of strcpy. Do not ever use strncpy, this is
|
|
older, slower, and does not add proper zero termination.
|
|
For the same reason, use snprintf if really needed. Note though, that using
|
|
ircsprintf with a bigger buffer (eg: 1024 bytes) is MUCH faster, so preferably
|
|
use that instead of snprintf. The same can be true for strcpy vs strlcpy in
|
|
some circumstances as well.
|
|
|
|
11. Speed. When optimizing or writing code, keep in mind that readability and
|
|
stability comes first, and after that comes speed. So we'd rather prefer some
|
|
readable code (even if difficult) over some odd highly optimized routine which
|
|
nobody understands, is difficult to extend, and might have several bugs.
|
|
As mentioned earlier: use ircsprintf, not sprintf (this is because ircsprintf
|
|
is optimized for simple strings like the ones we use).
|
|
Prefer ircsprintf with a bigger buffer over the use of snprintf, since
|
|
ircsprintf is much faster.
|
|
|
|
12. Initialize your structs and use the proper memory calls.
|
|
In UnrealIRCd we use MyMalloc, MyMallocEx and MyFree (so not malloc/free).
|
|
MyMalloc usually maps to malloc, and MyMallocEx is a malloc plus filling
|
|
the memory area (eg: the struct) with zero's (a la calloc).
|
|
Use of MyMallocEx is suggested. In general you should not be using MyMalloc.
|
|
"But MyMalloc is faster!" you might say. This is true, but using MyMallocEx
|
|
has very little speed impact and enourmous benefits: people tend to forget
|
|
to set certain fields in the struct to NULL, or much more common: when
|
|
someone later on (eg: 1 year later) adds a field to a struct, there could
|
|
be several places he/she needs to update to make sure x->something is NULL
|
|
after allocating a new struct. Bad idea.
|
|
Little speed impact, huge stability benefits, easy decision ;).
|
|
|
|
13. Comment your code! This should speak for itself...
|
|
Put comments wherever you think they are needed, to aid any further coders
|
|
with reading your code.. and, in fact, it will aid yourself as well if you
|
|
would look back at your code 2 years later.
|
|
If there's some obscure pitfall, do mention it! Don't just "hope" a next
|
|
author will see it like you did.
|
|
|
|
14. Use enums whenever possible, rather than #define constants. Besides making
|
|
things more clean, it also aids debugging.
|
|
|
|
15. Whenever you add a new directive or setting, be sure to add documentation
|
|
for it in unreal32docs, and for new commands in help.conf as well.
|
|
|
|
16. Whenever you add a new set:: item, be sure to add it to /stats S
|
|
|