diff options
Diffstat (limited to 'share')
| -rw-r--r-- | share/misc/style | 199 | ||||
| -rw-r--r-- | share/misc/vimrc | 7 |
2 files changed, 206 insertions, 0 deletions
diff --git a/share/misc/style b/share/misc/style new file mode 100644 index 0000000..03bcc72 --- /dev/null +++ b/share/misc/style @@ -0,0 +1,199 @@ +/* + * Copyright (c) 2023 Ian Marco Moffett and the VegaOS team. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of VegaOS nor the names of its + * contributors may be used to endorse or promote products derived from + * this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#include <sys/cdefs.h> + +/* + * Vim config in share/misc/vimrc + */ + +/* + * Metadata goes in *.c files + */ +__KERNEL_META("$Vega$: style.c, Ian Marco Moffett, " + "Vega style guide"); +/* + * VERY important single-line comments look like this. + */ + +/* Most single-line comments look like this. */ + +/* + * Multi-line comments look like this. Make them real sentences. Fill + * them so they look like real paragraphs. + */ + +/* + * Attempt to wrap lines longer than 80 characters appropriately. + * Refer to the examples below for more information. + */ + +/* + * EXAMPLE HEADER FILE. + * A header file should protect itself against + * multiple inclusion. + */ + #ifndef _SYS_FOO_H_ + #define _SYS_FOO_H_ + + +/* + * extern declarations must only appear in header files, not in .c + * files, so the same declaration is used by the .c file defining it + * and the .c file using it, giving the compiler the opportunity to + * detect type errors. + * + * extern function declarations should not use the extern keyword, + * which is unnecessary. + * + * Exception: A subroutine written in assembly in an adjacent .S file, + * which is used only in one .c file, may be declared in the .c file. + */ +extern int g_foo; + +int funnify(const char *s); + +#endif /* !_SYS_FOO_H_ */ + +/* + * END OF EXAMPLE HEADER FILE + */ + +/* + * If a header file requires structures, defines, typedefs, etc. from + * another header file it should include that header file and not depend + * on the including file for that header including both. If there are + * exceptions to this for specific headers it should be clearly documented + * in the headers and, if appropriate, the documentation. Nothing in this + * rule should suggest relaxation of the multiple inclusion rule and the + * application programmer should be free to include both regardless. + */ + +/* + * Kernel include files come first. + */ +#include <sys/param.h> /* <sys/param.h> first, */ +#include <sys/types.h> /* <sys/types.h> next, */ +#include <sys/ioctl.h> /* and then the rest, */ +#include <sys/socket.h> /* sorted lexicographically. */ +#include <sys/stat.h> +#include <sys/wait.h> + + +/* + * Macros are capitalized, parenthesized, and should avoid side-effects. + * If they are an inline expansion of a function, the function is defined + * all in lowercase, the macro has the same name all in uppercase. + * If the macro is an expression, wrap the expression in parentheses. + * If the macro is more than a single statement, use ``do { ... } while (0)'' + * or ``do { ... } while (false)'', so that a trailing semicolon works. + * Right-justify the backslashes; it makes it easier to read. + */ +#define MACRO(v, w, x, y) \ + do { \ + v = (x) + (y); \ + w = (y) + 2; \ + } while (0) + +}; + +/* + * Sometimes we want a macro to be conditionally defined for debugging + * and expand to nothing (but still as statement) when we are not debugging: + */ +#if defined(FOO_DEBUG) +#define DPRINTF(...) KDEBUG(__VA_ARGS__) +#else +#define DPRINTF(...) __nothing +#endif /* defined(FOO_DEBUG) */ + +/* + * The function type must be declared on a line by itself + * preceding the function. + */ +static char * +function(int fooy) +{ + /* + * When declaring variables in functions, multiple variables per line + * are okay. If a line overflows reuse the type keyword. + * + * Function prototypes and external data declarations should go in a + * suitable include file. + * + * Avoid initializing variables in the declarations; move + * declarations next to their first use, and initialize + * opportunistically. This avoids over-initialization and + * accidental bugs caused by declaration reordering. + */ + int foo, bar; + + foo = 0; + bar = 0; + /* + * Casts and sizeof's are not followed by a space. + * + * We parenthesize sizeof expressions to clarify their precedence: + * + * sizeof(e) + 4 + * not: + * sizeof e + 4 + * + * We don't put a space before the parenthesis so that it looks like + * a function call. We always parenthesize the sizeof expression for + * consistency. + * + * On the other hand, we don't parenthesize the return statement + * because there is never a precedence ambiguity situation (it is + * a single statement). + * + * NULL is any pointer type, and doesn't need to be cast, so use + * NULL instead of (struct foo *)0 or (struct foo *)NULL. Also, + * test pointers against NULL because it indicates the type of the + * expression to the user. I.e. use: + * + * (p = f()) == NULL + * not: + * !(p = f()) + * + * Don't use `!' for tests unless it's a boolean. + * E.g. use "if (*p == '\0')", not "if (!*p)". + * + * Routines returning ``void *'' should not have their return + * values cast to more specific pointer types. + * + * Prefer sizeof(*var) over sizeof(type) because if type changes, + * the change needs to be done in one place. + * + * Prefer EXIT_FAILURE instead of random error codes. + */ + + /* No parentheses are needed around the return value. */ + return 0; +} diff --git a/share/misc/vimrc b/share/misc/vimrc new file mode 100644 index 0000000..f8a2ba8 --- /dev/null +++ b/share/misc/vimrc @@ -0,0 +1,7 @@ +set cindent +set cinoptions=(4200,u4200,+0.5s,*500,:0,t0,U4200 +set indentexpr=IgnoreParenIndent() +set indentkeys=0{,0},0),:,0#,!^F,o,O,e +set sw=4 ts=4 +set softtabstop=4 +set expandtab |