1.\"- 2.\" Copyright (c) 1995-2005 The FreeBSD Project 3.\" All rights reserved. 4.\" 5.\" Redistribution and use in source and binary forms, with or without 6.\" modification, are permitted provided that the following conditions 7.\" are met: 8.\" 1. Redistributions of source code must retain the above copyright 9.\" notice, this list of conditions and the following disclaimer. 10.\" 2. Redistributions in binary form must reproduce the above copyright 11.\" notice, this list of conditions and the following disclaimer in the 12.\" documentation and/or other materials provided with the distribution. 13.\" 14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 17.\" ARE DISCLAIMED. IN NO EVENT SHALL [your name] OR CONTRIBUTORS BE LIABLE 18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24.\" SUCH DAMAGE. 25.\" 26.\" From: @(#)style 1.14 (Berkeley) 4/28/95 27.\" $FreeBSD$ 28.\" 29.Dd November 16, 2017 30.Dt STYLE 9 31.Os 32.Sh NAME 33.Nm style 34.Nd "kernel source file style guide" 35.Sh DESCRIPTION 36This file specifies the preferred style for kernel source files in the 37.Fx 38source tree. 39It is also a guide for the preferred userland code style. 40Many of the style rules are implicit in the examples. 41Be careful to check the examples before assuming that 42.Nm 43is silent on an issue. 44.Bd -literal 45/* 46 * Style guide for FreeBSD. Based on the CSRG's KNF (Kernel Normal Form). 47 * 48 * @(#)style 1.14 (Berkeley) 4/28/95 49 * $FreeBSD$ 50 */ 51 52/* 53 * VERY important single-line comments look like this. 54 */ 55 56/* Most single-line comments look like this. */ 57 58/* 59 * Multi-line comments look like this. Make them real sentences. Fill 60 * them so they look like real paragraphs. 61 */ 62.Ed 63.Pp 64The copyright header should be a multi-line comment, with the first 65line of the comment having a dash after the star like so: 66.Bd -literal 67/*- 68 * Copyright (c) 1984-2025 John Q. Public 69 * All rights reserved. 70 * 71 * Long, boring license goes here, but trimmed for brevity 72 */ 73.Ed 74.Pp 75An automatic script collects license information from the tree for 76all comments that start in the first column with 77.Dq Li "/*-" . 78If you desire to flag 79.Xr indent 1 80to not reformat a comment that starts in the first column which is not a 81license or copyright notice, change the dash to a star for those 82comments. 83Comments starting in columns other than the first are never 84considered license statements. 85.Pp 86After any copyright header, there is a blank line, and the 87.Li $\&FreeBSD$ 88for non C/C++ language source files. 89Version control system ID tags should only exist once in a file 90(unlike in this one). 91Non-C/C++ source files follow the example above, while C/C++ source files 92follow the one below. 93All VCS (version control system) revision identification in files obtained 94from elsewhere should be maintained, including, where applicable, multiple IDs 95showing a file's history. 96In general, do not edit foreign IDs or their infrastructure. 97Unless otherwise wrapped (such as 98.Dq Li "#if defined(LIBC_SCCS)" ) , 99enclose both in 100.Dq Li "#if 0 ... #endif" 101to hide any uncompilable bits 102and to keep the IDs out of object files. 103Only add 104.Dq Li "From: " 105in front of foreign VCS IDs if the file is renamed. 106.Bd -literal 107#if 0 108#ifndef lint 109static char sccsid[] = "@(#)style 1.14 (Berkeley) 4/28/95"; 110#endif /* not lint */ 111#endif 112 113#include <sys/cdefs.h> 114__FBSDID("$FreeBSD$"); 115.Ed 116.Pp 117Leave one blank line before the header files. 118.Pp 119Kernel include files 120.Pa ( sys/*.h ) 121come first. 122If 123.In sys/cdefs.h 124is needed for 125.Fn __FBSDID , 126include it first. 127If either 128.In sys/types.h 129or 130.In sys/param.h 131is needed, include it before other include files. 132.Po 133.In sys/param.h 134includes 135.In sys/types.h ; 136do not include both. 137.Pc 138The remaining kernel headers should be sorted alphabetically. 139.Bd -literal 140#include <sys/types.h> /* Non-local includes in angle brackets. */ 141#include <sys/endian.h> 142#include <sys/lock.h> 143#include <sys/queue.h> 144.Ed 145.Pp 146For a network program, put the network include files next. 147.Bd -literal 148#include <net/if.h> 149#include <net/if_dl.h> 150#include <net/route.h> 151#include <netinet/in.h> 152#include <protocols/rwhod.h> 153.Ed 154.Pp 155Do not include files from 156.Pa /usr/include 157in the kernel. 158.Pp 159Leave a blank line before the next group, the 160.Pa /usr/include 161files, 162which should be sorted alphabetically by name. 163.Bd -literal 164#include <stdio.h> 165.Ed 166.Pp 167Global pathnames are defined in 168.In paths.h . 169Pathnames local 170to the program go in 171.Qq Pa pathnames.h 172in the local directory. 173.Bd -literal 174#include <paths.h> 175.Ed 176.Pp 177Leave another blank line before the local include files. 178.Bd -literal 179#include "pathnames.h" /* Local includes in double quotes. */ 180.Ed 181.Pp 182Do not 183.Ic #define 184or declare names in the implementation namespace except 185for implementing application interfaces. 186.Pp 187The names of 188.Dq unsafe 189macros (ones that have side effects), and the names of macros for 190manifest constants, are all in uppercase. 191The expansions of expression-like macros are either a single token 192or have outer parentheses. 193Put a single tab character between the 194.Ic #define 195and the macro name. 196If a macro is an inline expansion of a function, the function name is 197all in lowercase and the macro has the same name all in uppercase. 198.\" XXX the above conflicts with ANSI style where the names are the 199.\" same and you #undef the macro (if any) to get the function. 200.\" It is not followed for MALLOC(), and not very common if inline 201.\" functions are used. 202Right-justify the 203backslashes; it makes it easier to read. 204If the macro encapsulates a compound statement, enclose it in a 205.Ic do 206loop, 207so that it can safely be used in 208.Ic if 209statements. 210Any final statement-terminating semicolon should be 211supplied by the macro invocation rather than the macro, to make parsing easier 212for pretty-printers and editors. 213.Bd -literal 214#define MACRO(x, y) do { \e 215 variable = (x) + (y); \e 216 (y) += 2; \e 217} while (0) 218.Ed 219.Pp 220When code is conditionally compiled using 221.Ic #ifdef 222or 223.Ic #if , 224a comment may be added following the matching 225.Ic #endif 226or 227.Ic #else 228to permit the reader to easily discern where conditionally compiled code 229regions end. 230This comment should be used only for (subjectively) long regions, regions 231greater than 20 lines, or where a series of nested 232.Ic #ifdef 's 233may be confusing to the reader. 234Exceptions may be made for cases where code is conditionally not compiled for 235the purposes of 236.Xr lint 1 , 237even though the uncompiled region may be small. 238The comment should be separated from the 239.Ic #endif 240or 241.Ic #else 242by a single space. 243For short conditionally compiled regions, a closing comment should not be 244used. 245.Pp 246The comment for 247.Ic #endif 248should match the expression used in the corresponding 249.Ic #if 250or 251.Ic #ifdef . 252The comment for 253.Ic #else 254and 255.Ic #elif 256should match the inverse of the expression(s) used in the preceding 257.Ic #if 258and/or 259.Ic #elif 260statements. 261In the comments, the subexpression 262.Dq Li defined(FOO) 263is abbreviated as 264.Dq Li FOO . 265For the purposes of comments, 266.Dq Ic #ifndef Li FOO 267is treated as 268.Dq Ic #if Li !defined(FOO) . 269.Bd -literal 270#ifdef KTRACE 271#include <sys/ktrace.h> 272#endif 273 274#ifdef COMPAT_43 275/* A large region here, or other conditional code. */ 276#else /* !COMPAT_43 */ 277/* Or here. */ 278#endif /* COMPAT_43 */ 279 280#ifndef COMPAT_43 281/* Yet another large region here, or other conditional code. */ 282#else /* COMPAT_43 */ 283/* Or here. */ 284#endif /* !COMPAT_43 */ 285.Ed 286.Pp 287The project is slowly moving to use the 288.St -isoC-99 289unsigned integer identifiers of the form 290.Vt uintXX_t 291in preference to the older 292.Bx Ns -style 293integer identifiers of the form 294.Vt u_intXX_t . 295New code should use the former, and old code should be converted to 296the new form if other major work is being done in that area and 297there is no overriding reason to prefer the older 298.Bx Ns -style . 299Like white-space commits, care should be taken in making 300.Vt uintXX_t 301only commits. 302.Pp 303Similarly, the project is slowly moving to use the 304.St -isoC-99 305.Vt bool 306in preference to the older 307.Vt int 308or 309.Vt boolean_t . 310New code should use 311.Vt bool , 312and old code may be converted if it is 313reasonable to do so. 314Literal values are named 315.Dv true 316and 317.Dv false . 318These are preferred to the old spellings 319.Dv TRUE 320and 321.Dv FALSE . 322Userspace code should include 323.In stdbool.h , 324while kernel code should include 325.In sys/types.h . 326.Pp 327Enumeration values are all uppercase. 328.Bd -literal 329enum enumtype { ONE, TWO } et; 330.Ed 331.Pp 332The use of internal_underscores in identifiers is preferred over 333camelCase or TitleCase. 334.Pp 335In declarations, do not put any whitespace between asterisks and 336adjacent tokens, except for tokens that are identifiers related to 337types. 338(These identifiers are the names of basic types, type 339qualifiers, and 340.Ic typedef Ns -names 341other than the one being declared.) 342Separate these identifiers from asterisks using a single space. 343.Pp 344When declaring variables in structures, declare them sorted by use, then 345by size (largest to smallest), and then in alphabetical order. 346The first category normally does not apply, but there are exceptions. 347Each one gets its own line. 348Try to make the structure 349readable by aligning the member names using either one or two tabs 350depending upon your judgment. 351You should use one tab only if it suffices to align at least 90% of 352the member names. 353Names following extremely long types 354should be separated by a single space. 355.Pp 356Major structures should be declared at the top of the file in which they 357are used, or in separate header files if they are used in multiple 358source files. 359Use of the structures should be by separate declarations 360and should be 361.Ic extern 362if they are declared in a header file. 363.Bd -literal 364struct foo { 365 struct foo *next; /* List of active foo. */ 366 struct mumble amumble; /* Comment for mumble. */ 367 int bar; /* Try to align the comments. */ 368 struct verylongtypename *baz; /* Won't fit in 2 tabs. */ 369}; 370struct foo *foohead; /* Head of global foo list. */ 371.Ed 372.Pp 373Use 374.Xr queue 3 375macros rather than rolling your own lists, whenever possible. 376Thus, 377the previous example would be better written: 378.Bd -literal 379#include <sys/queue.h> 380 381struct foo { 382 LIST_ENTRY(foo) link; /* Use queue macros for foo lists. */ 383 struct mumble amumble; /* Comment for mumble. */ 384 int bar; /* Try to align the comments. */ 385 struct verylongtypename *baz; /* Won't fit in 2 tabs. */ 386}; 387LIST_HEAD(, foo) foohead; /* Head of global foo list. */ 388.Ed 389.Pp 390Avoid using typedefs for structure types. 391Typedefs are problematic because they do not properly hide their 392underlying type; for example you need to know if the typedef is 393the structure itself or a pointer to the structure. 394In addition they must be declared exactly once, whereas an 395incomplete structure type can be mentioned as many times as 396necessary. 397Typedefs are difficult to use in stand-alone header files: 398the header that defines the typedef must be included 399before the header that uses it, or by the header that uses 400it (which causes namespace pollution), or there must be a 401back-door mechanism for obtaining the typedef. 402.Pp 403When convention requires a 404.Ic typedef , 405make its name match the struct tag. 406Avoid typedefs ending in 407.Dq Li _t , 408except as specified in Standard C or by 409.Tn POSIX . 410.Bd -literal 411/* Make the structure name match the typedef. */ 412typedef struct bar { 413 int level; 414} BAR; 415typedef int foo; /* This is foo. */ 416typedef const long baz; /* This is baz. */ 417.Ed 418.Pp 419All functions are prototyped somewhere. 420.Pp 421Function prototypes for private functions (i.e., functions not used 422elsewhere) go at the top of the first source module. 423Functions 424local to one source module should be declared 425.Ic static . 426.Pp 427Functions used from other parts of the kernel are prototyped in the 428relevant include file. 429Function prototypes should be listed in a logical order, preferably 430alphabetical unless there is a compelling reason to use a different 431ordering. 432.Pp 433Functions that are used locally in more than one module go into a 434separate header file, e.g.\& 435.Qq Pa extern.h . 436.Pp 437Do not use the 438.Dv __P 439macro. 440.Pp 441In general code can be considered 442.Dq "new code" 443when it makes up about 50% or more of the file(s) involved. 444This is enough 445to break precedents in the existing code and use the current 446.Nm 447guidelines. 448.Pp 449The kernel has a name associated with parameter types, e.g., in the kernel 450use: 451.Bd -literal 452void function(int fd); 453.Ed 454.Pp 455In header files visible to userland applications, prototypes that are 456visible must use either 457.Dq protected 458names (ones beginning with an underscore) 459or no names with the types. 460It is preferable to use protected names. 461E.g., use: 462.Bd -literal 463void function(int); 464.Ed 465.Pp 466or: 467.Bd -literal 468void function(int _fd); 469.Ed 470.Pp 471Prototypes may have an extra space after a tab to enable function names 472to line up: 473.Bd -literal 474static char *function(int _arg, const char *_arg2, struct foo *_arg3, 475 struct bar *_arg4); 476static void usage(void); 477 478/* 479 * All major routines should have a comment briefly describing what 480 * they do. The comment before the "main" routine should describe 481 * what the program does. 482 */ 483int 484main(int argc, char *argv[]) 485{ 486 char *ep; 487 long num; 488 int ch; 489.Ed 490.Pp 491For consistency, 492.Xr getopt 3 493should be used to parse options. 494Options 495should be sorted in the 496.Xr getopt 3 497call and the 498.Ic switch 499statement, unless 500parts of the 501.Ic switch 502cascade. 503Elements in a 504.Ic switch 505statement that cascade should have a 506.Li FALLTHROUGH 507comment. 508Numerical arguments should be checked for accuracy. 509Code which is unreachable for non-obvious reasons may be marked /* 510.Li NOTREACHED 511*/. 512.Bd -literal 513 while ((ch = getopt(argc, argv, "abNn:")) != -1) 514 switch (ch) { /* Indent the switch. */ 515 case 'a': /* Don't indent the case. */ 516 aflag = 1; /* Indent case body one tab. */ 517 /* FALLTHROUGH */ 518 case 'b': 519 bflag = 1; 520 break; 521 case 'N': 522 Nflag = 1; 523 break; 524 case 'n': 525 num = strtol(optarg, &ep, 10); 526 if (num <= 0 || *ep != '\e0') { 527 warnx("illegal number, -n argument -- %s", 528 optarg); 529 usage(); 530 } 531 break; 532 case '?': 533 default: 534 usage(); 535 } 536 argc -= optind; 537 argv += optind; 538.Ed 539.Pp 540Space after keywords 541.Pq Ic if , while , for , return , switch . 542Two styles of braces 543.Ql ( \&{ 544and 545.Ql \&} ) 546are allowed for single line statements. 547Either they are used for all single statements, or 548they are used only where needed for clarity. 549Usage within a function should be consistent. 550Forever loops are done with 551.Ic for Ns 's , 552not 553.Ic while Ns 's . 554.Bd -literal 555 for (p = buf; *p != '\e0'; ++p) 556 ; /* nothing */ 557 for (;;) 558 stmt; 559 for (;;) { 560 z = a + really + long + statement + that + needs + 561 two + lines + gets + indented + four + spaces + 562 on + the + second + and + subsequent + lines; 563 } 564 for (;;) { 565 if (cond) 566 stmt; 567 } 568 if (val != NULL) 569 val = realloc(val, newsize); 570.Ed 571.Pp 572Parts of a 573.Ic for 574loop may be left empty. 575Do not put declarations 576inside blocks unless the routine is unusually complicated. 577.Bd -literal 578 for (; cnt < 15; cnt++) { 579 stmt1; 580 stmt2; 581 } 582.Ed 583.Pp 584Indentation is an 8 character tab. 585Second level indents are four spaces. 586If you have to wrap a long statement, put the operator at the end of the 587line. 588.Bd -literal 589 while (cnt < 20 && this_variable_name_is_too_long && 590 ep != NULL) 591 z = a + really + long + statement + that + needs + 592 two + lines + gets + indented + four + spaces + 593 on + the + second + and + subsequent + lines; 594.Ed 595.Pp 596Do not add whitespace at the end of a line, and only use tabs 597followed by spaces 598to form the indentation. 599Do not use more spaces than a tab will produce 600and do not use spaces in front of tabs. 601.Pp 602Closing and opening braces go on the same line as the 603.Ic else . 604Braces that are not necessary may be left out. 605.Bd -literal 606 if (test) 607 stmt; 608 else if (bar) { 609 stmt; 610 stmt; 611 } else 612 stmt; 613.Ed 614.Pp 615No spaces after function names. 616Commas have a space after them. 617No spaces 618after 619.Ql \&( 620or 621.Ql \&[ 622or preceding 623.Ql \&] 624or 625.Ql \&) 626characters. 627.Bd -literal 628 error = function(a1, a2); 629 if (error != 0) 630 exit(error); 631.Ed 632.Pp 633Unary operators do not require spaces, binary operators do. 634Do not use parentheses unless they are required for precedence or unless the 635statement is confusing without them. 636Remember that other people may 637confuse easier than you. 638Do YOU understand the following? 639.Bd -literal 640 a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1; 641 k = !(l & FLAGS); 642.Ed 643.Pp 644Exits should be 0 on success, or 1 on failure. 645.Bd -literal 646 exit(0); /* 647 * Avoid obvious comments such as 648 * "Exit 0 on success." 649 */ 650} 651.Ed 652.Pp 653The function type should be on a line by itself 654preceding the function. 655The opening brace of the function body should be 656on a line by itself. 657.Bd -literal 658static char * 659function(int a1, int a2, float fl, int a4) 660{ 661.Ed 662.Pp 663When declaring variables in functions declare them sorted by size, 664then in alphabetical order; multiple ones per line are okay. 665If a line overflows reuse the type keyword. 666.Pp 667Be careful to not obfuscate the code by initializing variables in 668the declarations. 669Use this feature only thoughtfully. 670DO NOT use function calls in initializers. 671.Bd -literal 672 struct foo one, *two; 673 double three; 674 int *four, five; 675 char *six, seven, eight, nine, ten, eleven, twelve; 676 677 four = myfunction(); 678.Ed 679.Pp 680Do not declare functions inside other functions; ANSI C says that 681such declarations have file scope regardless of the nesting of the 682declaration. 683Hiding file declarations in what appears to be a local 684scope is undesirable and will elicit complaints from a good compiler. 685.Pp 686Casts and 687.Ic sizeof Ns 's 688are not followed by a space. 689Note that 690.Xr indent 1 691does not understand this rule. 692.Ic sizeof Ns 's 693are written with parenthesis always. 694The redundant parenthesis rules do not apply to 695.Fn sizeof var 696instances. 697.Pp 698.Dv NULL 699is the preferred null pointer constant. 700Use 701.Dv NULL 702instead of 703.Vt ( "type *" ) Ns 0 704or 705.Vt ( "type *" ) Ns Dv NULL 706in contexts where the compiler knows the 707type, e.g., in assignments. 708Use 709.Vt ( "type *" ) Ns Dv NULL 710in other contexts, 711in particular for all function args. 712(Casting is essential for 713variadic args and is necessary for other args if the function prototype 714might not be in scope.) 715Test pointers against 716.Dv NULL , 717e.g., use: 718.Bd -literal 719(p = f()) == NULL 720.Ed 721.Pp 722not: 723.Bd -literal 724!(p = f()) 725.Ed 726.Pp 727Do not use 728.Ic \&! 729for tests unless it is a boolean, e.g.\& use: 730.Bd -literal 731if (*p == '\e0') 732.Ed 733.Pp 734not: 735.Bd -literal 736if (!*p) 737.Ed 738.Pp 739Routines returning 740.Vt "void *" 741should not have their return values cast 742to any pointer type. 743.Pp 744Values in 745.Ic return 746statements should be enclosed in parentheses. 747.Pp 748Use 749.Xr err 3 750or 751.Xr warn 3 , 752do not roll your own. 753.Bd -literal 754 if ((four = malloc(sizeof(struct foo))) == NULL) 755 err(1, (char *)NULL); 756 if ((six = (int *)overflow()) == NULL) 757 errx(1, "number overflowed"); 758 return (eight); 759} 760.Ed 761.Pp 762Old-style function declarations look like this: 763.Bd -literal 764static char * 765function(a1, a2, fl, a4) 766 int a1, a2; /* Declare ints, too, don't default them. */ 767 float fl; /* Beware double vs. float prototype differences. */ 768 int a4; /* List in order declared. */ 769{ 770.Ed 771.Pp 772Use ANSI function declarations unless you explicitly need K&R compatibility. 773Long parameter lists are wrapped with a normal four space indent. 774.Pp 775Variable numbers of arguments should look like this: 776.Bd -literal 777#include <stdarg.h> 778 779void 780vaf(const char *fmt, ...) 781{ 782 va_list ap; 783 784 va_start(ap, fmt); 785 STUFF; 786 va_end(ap); 787 /* No return needed for void functions. */ 788} 789 790static void 791usage() 792{ 793 /* Insert an empty line if the function has no local variables. */ 794.Ed 795.Pp 796Use 797.Xr printf 3 , 798not 799.Xr fputs 3 , 800.Xr puts 3 , 801.Xr putchar 3 , 802whatever; it is faster and usually cleaner, not 803to mention avoiding stupid bugs. 804.Pp 805Usage statements should look like the manual pages 806.Sx SYNOPSIS . 807The usage statement should be structured in the following order: 808.Bl -enum 809.It 810Options without operands come first, 811in alphabetical order, 812inside a single set of brackets 813.Ql ( \&[ 814and 815.Ql \&] ) . 816.It 817Options with operands come next, 818also in alphabetical order, 819with each option and its argument inside its own pair of brackets. 820.It 821Required arguments 822(if any) 823are next, 824listed in the order they should be specified on the command line. 825.It 826Finally, 827any optional arguments should be listed, 828listed in the order they should be specified, 829and all inside brackets. 830.El 831.Pp 832A bar 833.Pq Ql \&| 834separates 835.Dq either-or 836options/arguments, 837and multiple options/arguments which are specified together are 838placed in a single set of brackets. 839.Bd -literal -offset 4n 840"usage: f [-aDde] [-b b_arg] [-m m_arg] req1 req2 [opt1 [opt2]]\en" 841"usage: f [-a | -b] [-c [-dEe] [-n number]]\en" 842.Ed 843.Bd -literal 844 (void)fprintf(stderr, "usage: f [-ab]\en"); 845 exit(1); 846} 847.Ed 848.Pp 849Note that the manual page options description should list the options in 850pure alphabetical order. 851That is, without regard to whether an option takes arguments or not. 852The alphabetical ordering should take into account the case ordering 853shown above. 854.Pp 855New core kernel code should be reasonably compliant with the 856.Nm 857guides. 858The guidelines for third-party maintained modules and device drivers are more 859relaxed but at a minimum should be internally consistent with their style. 860.Pp 861Stylistic changes (including whitespace changes) are hard on the source 862repository and are to be avoided without good reason. 863Code that is approximately 864.Fx 865KNF 866.Nm 867compliant in the repository must not diverge from compliance. 868.Pp 869Whenever possible, code should be run through a code checker 870(e.g., various static analyzers or 871.Nm cc Fl Wall ) 872and produce minimal warnings. 873.Sh SEE ALSO 874.Xr indent 1 , 875.Xr err 3 , 876.Xr warn 3 , 877.Xr style.Makefile 5 878.Sh HISTORY 879This manual page is largely based on the 880.Pa src/admin/style/style 881file from the 882.Bx 4.4 Lite2 883release, with occasional updates to reflect the current practice and 884desire of the 885.Fx 886project. 887.Pa src/admin/style/style 888is a codification by the CSRG of the programming style of Ken Thompson and 889Dennis Ritchie in 890.At v6 . 891