Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

C code style

Name: Anonymous 2011-10-26 17:39

C/C++ style general.
int main() {
}

int main()
{
}

2 space indent or 4? Spaces or tabs?

Name: Anonymous 2011-10-26 17:44

Opening brace on the same line, tab indents.

Name: Anonymous 2011-10-26 17:56

4 spaces, no egyptian brakets on functions.

Name: Anonymous 2011-10-26 17:59

8 spaces.

Name: Anonymous 2011-10-26 18:01

Matter of taste of course. Just don't put tabs somewhere else than at the beginning of a line.

Name: Anonymous 2011-10-26 18:07

Everything in one line.

Name: Anonymous 2011-10-26 18:18

opening brace always on the same line

tabs for indentation (set to 4 spaces in my editor, but everyone who reads my code can set this to his personal preference)

spaces for alignment

no space after a function name: int foo(char *a) { ...

a space after keywords: while (a != b) { ...

Name: Anonymous 2011-10-26 18:59

I find that http://www.kernel.org/doc/Documentation/CodingStyle has the proper K&R spirit and answers most of life's problems.

Name: Anonymous 2011-10-26 19:31

MAXIMUM TROLLING

Name: Anonymous 2011-10-26 21:06

- 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;

Etc.

Name: Anonymous 2011-10-26 22:23

>>10
- No space after function name;
Who the fuck does otherwise?

Name: sage 2011-10-26 22:39

>>11
Some people do.
Some people do incredibly stupid things when coding.

Name: Anonymous 2011-10-26 22:59

>>11

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: FrozenVoid 2011-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)

Name: Anonymous 2011-10-27 1:54

>>13
Just use \bword\b...

Name: FrozenVoid 2011-10-27 2:11

>>15
Match only word function
If( word == new ){ word = abc }
 word ( ) { }

Name: Anonymous 2011-10-27 2:21


int foo(int bar)
{
}



if(foo)
{
}
else if(bar)
{
}
else {
}


do {
} while(foo);



try {
}
catch(...)
{
}

Name: Anonymous 2011-10-28 11:43

>>17

int foo(int bar) {
}



if (foo) {
} else if (bar) {
} else {
}


do {
} while (foo);



try {
} catch (...) {
}


fixed it for you

Name: Anonymous 2011-10-28 12:04

>>16
\bword\b\s*([a-z0-9)(, [\]{}*]*)\s*\n

Name: Anonymous 2011-10-28 13:22

If you're working in any sort of pre-existing code base, keep the style of the surrounding code.

Don't change these.
Name: Email:
Entire Thread Thread List