X-Git-Url: https://repo.jachan.dev/qemu.git/blobdiff_plain/e68b98dc7237d76fdef5c5d403d0613b443102da..baca2b9e3a94be1690fc4a842a97b64a4c8f892c:/CODING_STYLE diff --git a/CODING_STYLE b/CODING_STYLE index 1ab13b6861..d46cfa5f65 100644 --- a/CODING_STYLE +++ b/CODING_STYLE @@ -1,6 +1,9 @@ -Qemu Coding Style +QEMU Coding Style ================= +Please use the script checkpatch.pl in the scripts directory to check +patches before submitting. + 1. Whitespace Of course, the most important aspect in any coding style is whitespace. @@ -10,7 +13,7 @@ of approximately fifteen parsecs. Many a flamewar have been fought and lost on this issue. QEMU indents are four spaces. Tabs are never used, except in Makefiles -where they have been irreversibly coded into the syntax by some moron. +where they have been irreversibly coded into the syntax. Spaces of course are superior to tabs because: - You have just one way to specify whitespace, not two. Ambiguity breeds @@ -41,13 +44,14 @@ Rationale: 3. Naming Variables are lower_case_with_underscores; easy to type and read. Structured -type names are in CamelCase; harder to type but standing out. Scalar type +type names are in CamelCase; harder to type but standing out. Enum type +names and function type names should also be in CamelCase. Scalar type names are lower_case_with_underscores_ending_with_a_t, like the POSIX uint64_t and family. Note that this last convention contradicts POSIX and is therefore likely to be changed. -Typedefs are used to eliminate the redundant 'struct' keyword. It is the -QEMU coding style. +When wrapping standard library functions, use the prefix qemu_ to alert +readers that they are seeing a wrapped version; otherwise avoid this prefix. 4. Block structure @@ -65,6 +69,10 @@ keyword. Example: printf("a was something else entirely.\n"); } +Note that 'else if' is considered a single statement; otherwise a long if/ +else if/else if/.../else sequence would need an indent for every else +statement. + An exception is the opening brace for a function; for reasons of tradition and clarity it comes on a line by itself: @@ -76,3 +84,24 @@ and clarity it comes on a line by itself: Rationale: a consistent (except for functions...) bracing style reduces ambiguity and avoids needless churn when lines are added or removed. Furthermore, it is the QEMU coding style. + +5. Declarations + +Mixed declarations (interleaving statements and declarations within blocks) +are not allowed; declarations should be at the beginning of blocks. In other +words, the code should not generate warnings if using GCC's +-Wdeclaration-after-statement option. + +6. Conditional statements + +When comparing a variable for (in)equality with a constant, list the +constant on the right, as in: + +if (a == 1) { + /* Reads like: "If a equals 1" */ + do_something(); +} + +Rationale: Yoda conditions (as in 'if (1 == a)') are awkward to read. +Besides, good compilers already warn users when '==' is mis-typed as '=', +even when the constant is on the right.