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