118 lines
3.1 KiB
Plaintext
118 lines
3.1 KiB
Plaintext
* C
|
|
|
|
The C {programming-languages programming language} was developed at Bell Labs in
|
|
the 1970s to implement the original UNIX kernel and userland. It's a general
|
|
purpose, imperative systems programming language with a static, weak typing
|
|
dicipline (due to void* and dynamic type casts).
|
|
|
|
It is an extremely portable language, with compilers available on most systems.
|
|
|
|
While it is standardized, various non-standard dialects of the language exist
|
|
like Plan 9 C.
|
|
|
|
** C is not a low level language.
|
|
|
|
C is often described as low-level and "close to the machine". This is mostly
|
|
true when it comes to memory with the manual memory management as well as the
|
|
pointer features. Its execution model, however, is modelled after a PDP-11 and
|
|
is therefore quite abstract on modern machines (which additionally makes it
|
|
harder to optimize on modern systems). The execution model C follows is called
|
|
the "C abstract machine".
|
|
|
|
Relevant: {https://queue.acm.org/detail.cfm?id=3212479 C Is Not a Low-level
|
|
Language}
|
|
|
|
** Style
|
|
|
|
Since C ignores much of the whitespace prevalent in source files it is possible
|
|
to write in a variety of C styles. These differ in where they put their curly
|
|
braces, indentation level and other details.
|
|
|
|
*** My C style
|
|
|
|
My C style is based on a combination of the {https://www.kernel.org/doc/html/latest/process/coding-style.html
|
|
Linux kernel} style and the {http://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9
|
|
Plan 9} style with a few changes of my own.
|
|
|
|
Standard library ``include``s come first, then ``<sys/*>`` headers, then other
|
|
``/usr/include/`` libraries (like ``<SDL/SDL2.h>``), and finally local
|
|
``include``s.
|
|
|
|
``
|
|
/* normal comments look like this */
|
|
|
|
// temporary comments (like TODOs) look like this
|
|
|
|
/*
|
|
* really important normal comments look like this
|
|
*/
|
|
|
|
/* comments spanning multiple lines look
|
|
* like this
|
|
*/
|
|
``
|
|
|
|
Numbers from ``stdint.h`` should be used when the number of bits in the number
|
|
is of any importance. For just "a number" an ``int`` suffices. ``size_t`` is
|
|
used for variables holding an index.
|
|
|
|
Functions have their return types and opening curly braces on separate lines:
|
|
|
|
``
|
|
int
|
|
two(void)
|
|
{
|
|
return 2;
|
|
}
|
|
``
|
|
|
|
This makes it easy to search for function definitions with a simple
|
|
``/^func\(/`` regular expression.
|
|
|
|
All other statements have their curly braces on the same line:
|
|
|
|
``
|
|
buf[10];
|
|
|
|
for (int i = 0; i < 10; i++) {
|
|
buf[i] = i;
|
|
printf("%d\n", i);
|
|
}
|
|
``
|
|
|
|
Braces are not used for statements spanning only a single line:
|
|
|
|
``
|
|
if (x == 2) {
|
|
printf("%d\n", x);
|
|
y = x;
|
|
}
|
|
|
|
if (y == x)
|
|
printf("%d\n", y);
|
|
``
|
|
|
|
Pointer definitions are on the form ``int *x`` rather than ``int* x``. This is
|
|
because it looks better when defining multiple variables:
|
|
|
|
``
|
|
int *x, *y;
|
|
|
|
/* these versions are ugly: */
|
|
int* x, *y;
|
|
|
|
int* x,* y;
|
|
``
|
|
|
|
However, when casting to another pointer type (say, ``int``), use ``(int*)x``.
|
|
|
|
Casts to ``void*`` are implicit in C, so do not explicitly cast pointers to
|
|
``void*``.
|
|
|
|
Indentation is done with 4 spaces.
|
|
|
|
I ``typedef`` my structs and my enums on the form ``struct_name_t`` and
|
|
``enum_name_t``.
|
|
|
|
Everything is named in snake case with all lower case letters.
|