111 lines · 2.4 KiB

Alpine Linux coding style

Thank you for taking interest in contributing to our aports repository. As consistency and readability are so important for the quality of our APKBUILD and thus the quality of Alpine Linux, we kindly ask to follow these recommendations.

Language

Alpine Linux APKBUILD files are inherently just POSIX shell scripts. Please avoid extensions, even if they work or are accepted by busybox ash. (using keyword local is an exception)

Naming convention

Use snake_case. Functions, variables etc. should be lower-cased with underscores to separate words.

Local ‘private’ variables and functions in global scope should be prefixed with a single underscore to avoid name collisions with internal variables in abuild.

Double underscores are reserved and should not be used.

_my_variable="data"

Bracing

Curly braces for functions should be on the same line.

prepare() {
	...
}

Markers to indicate a compound statement should be on the same line.

if …; then

	if [ true ]; then
		echo "It is so"
	fi
}

while …; do

	while ...; do
		...
	done

for …; do

	for x in foo bar baz; do
		...
	done

Spacing

All keywords and operators are separated by a space.

For cleanliness sake, ensure there is no trailing whitespace.

Identation

Indentation is one tab character per level, alignment is done using spaces. For example (using the >—–– characters to indicate a tab):

build()
{
>-------make DESTDIR="${pkgdir}" \
>-------     PREFIX="/usr"
}

This ensures code is always neatly aligned and properly indented.

Space before tab should be avoided.

Line length

A line should not be longer than 80 characters. While this is not a hard limit, it is strongly recommended to avoid having longer lines, as long lines reduce readability and invite deep nesting.

Variables

Quoting

Quote strings containing variables, command substitutions, spaces or shell meta characters, unless careful unquoted expansion is required.

Don’t quote literal integers.

Bracing

Only use curly braces around variables when needed.

foo="${foo}_bar"
foo_bar="$foo"

Subshell usage

Use $() syntax, not backticks.

Sorting

Some items tend to benefit from being sorted. A list of sources, dependencies etc. Always try to find a reasonable sort order, where alphabetically tends to be the most useful one.

Eval

eval is evil and should be avoided.

1	# Alpine Linux coding style
2
3	Thank you for taking interest in contributing to our aports repository.
4	As consistency and readability are so important for the quality of our APKBUILD
5	and thus the quality of Alpine Linux, we kindly ask to follow these
6	recommendations.
7
8	## Language
9	Alpine Linux APKBUILD files are inherently just POSIX shell scripts. Please avoid
10	extensions, even if they work or are accepted by busybox ash. (using keyword
11	`local` is an exception)
12
13	## Naming convention
14	Use snake_case. Functions, variables etc. should be lower-cased with
15	underscores to separate words.
16
17	Local 'private' variables and functions in global scope should be prefixed
18	with a single underscore to avoid name collisions with internal variables in
19	`abuild`.
20
21	Double underscores are reserved and should not be used.
22	```sh
23	_my_variable="data"
24	```
25
26	### Bracing
27	Curly braces for functions should be on the same line.
28
29	```sh
30	prepare() {
31	...
32	}
33	```
34
35	Markers to indicate a compound statement should be on the same line.
36
37
38	#### if ...; then
39	```sh
40	if [ true ]; then
41	echo "It is so"
42	fi
43	}
44	```
45
46	#### while ...; do
47	```sh
48	while ...; do
49	...
50	done
51	```
52
53	#### for ...; do
54	```sh
55	for x in foo bar baz; do
56	...
57	done
58	```
59
60	### Spacing
61	All keywords and operators are separated by a space.
62
63	For cleanliness sake, ensure there is no trailing whitespace.
64
65	## Identation
66	Indentation is one tab character per level, alignment is done using spaces.
67	For example (using the >------- characters to indicate a tab):
68	```sh
69	build()
70	{
71	>-------make DESTDIR="${pkgdir}" \
72	>------- PREFIX="/usr"
73	}
74	```
75
76	This ensures code is always neatly aligned and properly indented.
77
78	Space before tab should be avoided.
79
80	## Line length
81	A line should not be longer than 80 characters. While this is not a hard limit, it
82	is strongly recommended to avoid having longer lines, as long lines reduce
83	readability and invite deep nesting.
84
85	## Variables
86
87	### Quoting
88	Quote strings containing variables, command substitutions, spaces or shell meta
89	characters, unless careful unquoted expansion is required.
90
91	Don't quote _literal_ integers.
92
93	### Bracing
94	Only use curly braces around variables when needed.
95
96	```sh
97	foo="${foo}_bar"
98	foo_bar="$foo"
99	```
100
101	## Subshell usage
102	Use `$()` syntax, not backticks.
103
104	## Sorting
105	Some items tend to benefit from being sorted. A list of sources, dependencies
106	etc. Always try to find a reasonable sort order, where alphabetically tends to
107	be the most useful one.
108
109	## Eval
110	`eval` is evil and should be avoided.
111