diff options
Diffstat (limited to 'share/misc/style')
| -rw-r--r-- | share/misc/style | 209 |
1 files changed, 0 insertions, 209 deletions
diff --git a/share/misc/style b/share/misc/style deleted file mode 100644 index 0a994e8..0000000 --- a/share/misc/style +++ /dev/null @@ -1,209 +0,0 @@ -/* - * Copyright (c) 2023 Ian Marco Moffett and the Osmora 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 Hyra 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("$Hyra$: style.c, Ian Marco Moffett, " - "Hyra 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. - */ - -/* - * If your header as a manpage tied to it use - * write a comment similar to the below comment - */ - -/* - * For documentation: See foo(9) - */ - - #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; -} |