use d_printf instead of printf for display text reason: enable auto-substitution of translated language text

use SAFE_FREE instead of free reason: reduce traps due to null pointers

don't use bzero use memset, or ZERO_STRUCT and ZERO_STRUCTP macros reason: not POSIX

don't use strcpy and strlen (use safe_* equivalents) reason: to avoid traps due to buffer overruns

don't use getopt_long, use popt functions instead reason: portability

explicitly add const qualifiers on parm passing in functions where parm is input only (somewhat controversial but const can be #defined away)

when passing a va_list as an arg, or assigning one to another please use the VA_COPY() macro reason: on some platforms, va_list is a struct that must be initialized in each function...can SEGV if you don't.

discourage use of threads reason: portability (also see architecture.doc)

don't explicitly include new header files in C files - new h files should be included by adding them once to includes.h reason: consistency

don't explicitly extern functions (they are autogenerated by "make proto" into proto.h) reason: consistency

use endian safe macros when unpacking SMBs (see byteorder.h and internals.doc) reason: not everyone uses Intel

Note Unicode implications of charset handling (see internals.doc). See pull_* and push_* and convert_string functions. reason: Internationalization

Don't assume English only reason: See above

Try to avoid using in/out parameters (functions that return data which overwrites input parameters) reason: Can cause stability problems

Ensure copyright notices are correct, don't append Tridge's name to code that he didn't write. If you did not write the code, make sure that it can coexist with the rest of the Samba GPLed code.

Consider usage of DATA_BLOBs for length specified byte-data. reason: stability

Take advantage of tdbs for database like function reason: consistency

Don't access the SAM_ACCOUNT structure directly, they should be accessed via pdb_get...() and pdb_set...() functions. reason: stability, consistency

Don't check a password directly against the passdb, always use the check_password() interface. reason: long term pluggability

Try to use asprintf rather than pstrings and fstrings where possible

Use normal C comments / * instead of C++ comments // like this. Although the C++ comment format is part of the C99 standard, some older vendor C compilers do not accept it.

Try to write documentation for API functions and structures explaining the point of the code, the way it should be used, and any special conditions or results. Mark these with a double-star comment start / ** so that they can be picked up by Doxygen, as in this file.

Keep the scope narrow. This means making functions/variables static whenever possible. We don't want our namespace polluted. Each module should have a minimal number of externally visible functions or variables.

Use function pointers to keep knowledge about particular pieces of code isolated in one place. We don't want a particular piece of functionality to be spread out across lots of places - that makes for fragile, hand to maintain code. Instead, design an interface and use tables containing function pointers to implement specific functionality. This is particularly important for command interpreters.

Think carefully about what it will be like for someone else to add to and maintain your code. If it would be hard for someone else to maintain then do it another way.