Again, we live in the real world, and it is sometimes a
judgement call, the decision based more on real world
constraints people face than what the paper standard says.

"Once it _is_ in the tree, it's not really worth the patch noise to
go and fix it up."
Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/

case "$variable" in
pattern1)
	do this
	;;
pattern2)
	do that
	;;
esac

(incorrect)
cat hello > world < universe
echo hello >$world

(correct)
cat hello >world <universe
echo hello >"$world"

(incorrect)
if test -f hello; then
	do this
fi

(correct)
if test -f hello
then
	do this
fi

(incorrect)
grep blob verify_pack_result \
| awk -f print_1.awk \
| sort >actual &&
...

(correct)
grep blob verify_pack_result |
awk -f print_1.awk |
sort >actual &&
...

(incorrect)
my_function(){
	...

(correct)
my_function () {
	...

test -n "$x" -a "$a" = "$b"

is buggy and breaks when $x is "=", but

test -n "$x" && test "$a" = "$b"

does not have such a problem.

(incorrect)
local variable=$value
local variable=$(command args)

(correct)
local variable="$value"
local variable="$(command args)"

VAR=VAL command args

to temporarily set and export environment variable VAR only while
"command args" is running is handy, but this triggers an
unspecified behaviour according to POSIX when used for a command
that is not an external command (like shell functions).  Indeed,
dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T
ksh all make a temporary assignment without exporting the variable,
in such a case.  As it does not work portably across shells, do not
use this syntax for shell functions.  A common workaround is to do
an explicit export in a subshell, like so:

(incorrect)
VAR=VAL func args

(correct)
(
	VAR=VAL &&
	export VAR &&
	func args
)

but be careful that the effect "func" makes to the variables in the
current shell will be lost across the subshell boundary.

#if FOO
# include <foo.h>
# if BAR
#  include <bar.h>
# endif
#endif

New C99 features have been phased in gradually, if something's new
in C99 but not used yet don't assume that it's safe to use, some
compilers we target have only partial support for it. These are
considered safe to use:

      while (condition)
func(bar + 1);

and not:

      while( condition )
func (bar+1);

if (!ptr || cnt)
	BUG("empty array expected");

and not:

if (ptr == NULL || cnt != 0);
	BUG("empty array expected");

if (bla) {
	x = 1;
}

is frowned upon. But there are a few exceptions:

while (foo) {
	if (x)
		one();
	else
		two();
}

if (foo) {
	/*
	 * This one requires some explanation,
	 * so we're better off with braces to make
	 * it obvious that the indentation is correct.
	 */
	doit();
}

if (foo) {
	doit();
} else {
	one();
	two();
	three();
}

/*
 * A very long
 * multi-line comment.
 */

Note however that a comment that explains a translatable string to
translators uses a convention of starting with a magic token
"TRANSLATORS: ", e.g.

/*
 * TRANSLATORS: here is a comment that explains the string to
 * be translated, that follows immediately after it.
 */
_("Here is a translatable string explained by the above.");

while (i > lower_bound) {
	do something;
	i--;
}

Other people prefer to have the textual order of values match the
actual order of values in their comparison, so that they can
mentally draw a number line from left to right and place these
values in order, i.e.

while (lower_bound < i) {
	do something;
	i--;
}

Both are valid, and we use both.  However, the more "stable" the
stable side becomes, the more we tend to prefer the former
(comparison with a constant, "i > 0", is an extreme example).
Just do not mix styles in the same part of the code and mimic
existing styles in the neighbourhood.

      if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
              ...

while other people prefer to align the second and the subsequent
lines with the column immediately inside the opening parenthesis,
with tabs and spaces, following our "tabstop is always a multiple
of 8" convention:

   if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
           ...

Both are valid, and we use both.  Again, just do not mix styles in
the same part of the code and mimic existing styles in the
neighbourhood.

   if (the_beginning_of_a_very_long_expression_that_has_to
|| span_more_than_a_single_line_of_the_source_text) {

while other people prefer to leave the operator at the end of the
line:

   if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of_the_source_text) {

Both are valid, but we tend to use the latter more, unless the
expression gets fairly complex, in which case the former tends to
be easier to read.  Again, just do not mix styles in the same part
of the code and mimic existing styles in the neighbourhood.

if (a_very_long_variable * that_is_used_in +
    a_very_long_expression) {
	...

than

if (a_very_long_variable *
    that_is_used_in + a_very_long_expression) {
	...

There are some exceptions, because certain group of files that
implement an API all have to include the same header file that
defines the API and it is convenient to include <git-compat-util.h>
there.  Namely:

are allowed to assume that they do not have to include
<git-compat-util.h> themselves, as it is included as the first
'#include' in these header files.  These headers must be the first
header file to be "#include"d in them, though.

struct strbuf;

void strbuf_add(struct strbuf *buf, ...);

void strbuf_reset(struct strbuf *buf);

is preferred over:

struct strbuf;

void add_string(struct strbuf *buf, ...);

void reset_strbuf(struct strbuf *buf);

Historically, the '_1' suffix has been used in situations where:

The '_1' suffix can be used as a concise way to indicate these specific
cases. However, it is recommended to find a more descriptive name wherever
possible to improve the readability and maintainability of the code.

unsigned my_field:1;
unsigned other_field:1;
unsigned field_with_longer_name:1;

You can use this option instead of `--xyz`, but we might remove
support for it in future versions.

while keeping in mind that you can probably be less verbose, e.g.

Use this instead of `--xyz`. This option might be removed in future
versions.

A contributor asks their upstream to pull from them.

Note that this sounds ungrammatical and unnatural to those who
learned that "they" is only used for third-person plural, e.g.
those who learn English as a second language in some parts of the
world.

Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
conventions.