- Tab indents, space aligns;
- Opening braces always on the end of the line;
- Closing braces always on a single line;
- No space after function name;
- Spaces separating operands in an arithmetic expression;
- A space after if/while/for and others;
- else on the following line instead of straight ahead of the closing bracket from if;
- Separate logical code blocks with a single line (and possibly a one-line comment describing the thing);
- case aligned to the same level of the switch (to avoid too much indentation);
- Sane line lengths, but no strict limits (neither uberly retarded 80-column limit);
- Sane usage of macros, never mess with the lexical scope (no macros with braces, for example);
- Avoid typedefs for structs, unions or enums;
- Avoid "data hiding techniques" which force heap allocation (by using forward-declared structs with no definition and limit API to pointer usage), C is not meant for that;
- Proper usage of const, restrict, inline and static;
- Avoid "auxiliary typedefs" (which hide the underlying type, specially scalar types); it makes more difficult to printf()/scanf() data when needed. Let types appear clearly to the user whenever possible;
- Prefer descriptive names for abbreviations;
- Avoid polluting the namespace (no spurious #defines or useless declarations in header files);
- Respect the relevant standards (for example, define _POSIX_C_SOURCE when using POSIX and do not define _t-ending symbols);
- Avoid extensions or otherwise unportable code; if strictly necessary, protect the code with #ifdefs) or separate system-specific stuff on specific files;
- Use compatible types for comparison (for example, if looping against a sizeof(), prefer a size_t iterating variable);
- Mix signed/unsigned variables sparingly; use unsigned variables only when they make sense;
- Avoid register declarations, they're already quite obsolete and likely to be deprecated on C1X;
- Keep functions as simple as possible, but not simpler; don't litter the code with useless helper functions;
- Handle errors efficiently, care about error propagation, use assert() when debugging (and always compile release builds with NDEBUG defined);
- Prefer enum to #defines;
- Don't ever refer to GNU code, it's just overwhelmingly malcoded;
- Make proper use of the toolchain (make, the debugger, the profiler, the static checker, the coverage analyzer);
- Do mind writing portable makefiles or even compilation scripts for the systems you are targeting instead of depending on the terrible "autotools";
- Don't mix first-class documentation with code; avoid tools that process comment-tags for generating things, such as Doxygen;
If you put spaces after everything , it makes it easy to search for them , via the use of the regular expression , /word / , and then you wont get false positives like wordy .
Name:
FrozenVoid2011-10-27 1:42
>>13
This is retarded, you're using the wrong regexp:
search "function_name(" you will get no false positives
search "function_name "you will be flooded in false positives(esp in common names)