ruby.git - Ruby GIT repository

diff options

Diffstat (limited to 'ext/tk/lib/tk.rb')

0 files changed, 0 insertions, 0 deletions

WRITING C CODE ============== The code in the krb5 source tree largely follows BSD KNF (/usr/share/misc/style on NetBSD) except that it uses a four column basic offset. The style described here is a synthesis of BSD KNF and the GNU coding standards for the C language. The formatting described in the "Formatting Your Source Code" section of the GNU coding standards is mostly what we want, except we use BSD brace style and BSD-ish conventions for the spacing around operators. Formatting style for C code --------------------------- In general, use a four column basic offset, tab stops at eight columns. Indents should be tabified, i.e. continuous tabs followed by spaces if necessary if the indent isn't a multiple of eight columns. The "bsd" style in emacs cc-mode mostly does the right thing. You can use "M-x c-set-style" "bsd" to get this. Alternatively, you can use the "krb5" style that is included here. Labels, including case labels, are outdented by four columns. Continuations of statements are indented by an additional four columns. When continuing expressions this way, split the expression so that the newline goes before a binary operator rather than after it. Continuations of argument lists or parenthesized expressions should line up with the column after the opening parenthesis. Note that this may create width problems if you call a fuction deep in a bunch of nested control flow statements. Regardless, any expression split between lines should stil be split so that the newline goes before a binary operator rather than after it. The maximum width should be 79 columns. If you need more than this, consider rewriting the code so that it fits in 79 columns, since control flow that is nested deeply enough to require excessive width is also likely to be difficult to understand if not broken up. Exceptions may be made for long strings, though ANSI C string concatenation should work around that as well. Function names for definitions should start on column zero, on the line following their return type name, e.g. char * foo(int a) { /* ... */ } [just pretend that's really at column zero] The opening brace of a function definition should also be on column zero. Braces that open substatements, such as those following "if", "else", "while", "for", "do", and "switch", should be on the same line as the begining of the statement. This is sometimes called "hanging" braces. The corresponding closing brace should be at the same indentation level as the beginning of the statement. The "while" keyword in a do-while construct should sit on the same line as the closing brace of the substatement following "do": do { foo(); } while (0); If there is an "if" statement immediately following an "else" keyword, it should go on the same line immediately after the "else": if (x) { foo(); } else if (y) { bar(); } Comments to the right of code start in column 32. Comments not to the right of code are indented at the prevailing indent for the surrounding code. Make the comments complete sentences. If you need more than one line, make them into block comments, like this: /* * This is a block comment. It should consist of complete * sentences. * * Paragraphs should be separated by blank lines so that emacs * fill commands will work properly. */ Really important single-line comments should also be done in block form: /* * This is a really important one-line comment. */ In order to get the start and end delimiters for block comments to stay when you use emacs to fill paragraphs in the comments, set both the c-hanging-comment-starter-p and the c-hanging-comment-ender-p variables to nil. This will be done by the tentative "krb5" style for the emacs cc-mode. Spaces go after keywords, but not after function names. Do not, however, put a space after sizeof. Don't put a space after a cast operator, either. Spaces also do not go before parentheses that are argument lists for function calls even if the function call is through a pointer. Spaces go after commas in argument lists, as well as commas that are comma operators. Spaces also go between parts in a for loop, except for "forever" type loops. Use for statements rather than while statements to create forever loops. if (x) { p = calloc(1024, sizeof(int)); } cp = (*elem->fp)(1024); for (i = 0; i < 10; i++); for (;;) { /* ... */ } Binary operators get spaces, unary ones do not. Prefix and postfix operators also do not get spaces. The structure member operators "." and "->" count as postfix operators syntactically, not as binary operators. x = --a + b / c - d++; y = p->z.v[x]; Put spaces around the "?" and ":" in a conditional expression. x = y ? f() : g(); In general, do not parenthesize the argument of "return". Coding practices for C ---------------------- Assume, for most purposes, working ANSI/ISO C ('89, not '99) support, both for internal use and for applications compiling against Kerberos header files and libraries. Some exceptions are noted below. Do not use assignments as truth values. Rather than this: /* bad style */ if ((retval = krb5_foo())) /* ... */; do this: /* better style */ retval = krb5_foo(); if (retval) /* ... */; This makes the code easier to read, and also makes it easier to use debuggers. It may be excusable to put assignments into the conditional espression of a "while" statement, though, like: while ((ch = getopt(argc, argv, "abn")) != -1) /* ... */; Using assignments as truth values in conditional expressions may make code particularly impenetrable. There are at least three types of "zero" known to C. These are the integer zero (0), the null pointer constant (NULL), and the character constant zero ('\0'). Yes, these are usually all technically the integer zero. Use them in their correct contexts. (Purists will point out that 0 is a valid null pointer constant; still, do not use 0 to specify a null pointer constant. For further unconfusion, read the section on null pointer constants in the C FAQ.) Do not use a lone variable as a truth value unless it's of integer type. Thus: int i; char *cp; /* ... */ if (i) /* ... */; if (cp != NULL) { while (*cp != '\0') /* ... */; } Do not cast uses of NULL unless you're calling a function with a variable number of arguments, in which case you should cast it to to the appropriate pointer type. Likewise, do not cast the return value from malloc() and friends; the prototype should declare them properly as returning a void * and thus shouldn't require an explicit cast. Do not assume that realloc(NULL, size) will do the right thing, or that free(NULL) will do the right thing. ANSI guarantees that it will, but some old libraries (hopefully becoming obsolete) don't. Also, don't assume that malloc(0) will return a non-NULL pointer. Typically, though, the output of malloc(0) will be safe to pass to realloc() and free(). In any case, reading the section in the C FAQ on null pointers is highly recommended to remove confusion regarding null pointers in C, since this is a subject of much confusion to even experienced programmers. In particular, if you do not understand why using calloc() to allocate a struct that contains pointer members or why calling memset() to initialize such a struct to all-bytes-zero is wrong, reread that section again. (Note that there are *lots* of examples of code in the krb5 source tree that erroneously calls memset() to zero a struct, and we should fix these somehow eventually.) Control flow statements that have a single statement as their body


context:
space:
mode: