In majority of cases a programming language lets the programmer choose the visual/surface style in which to write the code -- one may choose names for variables, indent and align commands in a convenient way, insert comments and so on. This gives rise to various styles -- typically a programmer will have his own preferred style, kind of like handwriting, but once he works in a team, some compromise has to be found to which everyone must conform so as to keep the code nice, consistent and readable. Some project, e.g. Linux, have evolved quite good, tested and de facto standardized styles, so instead of inventing a custom style (which may not be as easy as it sounds) one may choose to adopt some of the existing styles.
There exist automatic code formatters, they are often called code beautifiers. But not everything can be automatized, for example inserting empty spaces to separate logically related parts of a sequential of code.
TODO: moar
Here we propose a programming style and C code formatting you may use in your programs. { It's basically a style I personally adopted and fine-tuned over many years of my programming. ~drummyfish } Remember that nothing is set in stone (except that you mustn't use tabs), the most important thing is usually to be consistent within a single project and to actually think about why you're doing things the way you're doing them. Keeping to the standard set here will gain you advantages such as increased readability for others already familiar with the same style and avoiding running into traps set by short-sighted decisions e.g. regarding identifiers. Try to think from the point of view of a programmer who gets just your source code without any way to communicate with you, make his life as easy as possible. Also suppose he's reading your code on a calculator. The LRS style/formatting rules follow:
if (a == b)
{
doSomething();
doSomething2();
}
else
{
doSomethingElse();
doSomethingElse2();
}
(a && b) || c
rather than a && b || c
.camelCase
for variables and functions (e.g. myVariable
). Global and big-scope variables should have a greatly descriptive, self-documenting name, even if long (e.g. getTicksSinceStart
, countryAreaKMSquared
), local/short-scope identifiers can be shorter (e.g. argBackup
within a single function), even just one letter (e.g. i
within a single loop).CapitalCamelCase
for data types (e.g. ImaginaryNumber
, GameState
etc.).ALL_CAPS_SNAKE_CASE
for macros and constants (e.g. PI
, MIN
, LOG_ERROR
, ...).S3L_
, SDL uses SDL
etc.). If you choose a prefix XYZ_
, prepend it to all global identifiers, it will prevent name clashes and help readability, e.g. when writing a renderer you will export identifiers such as XYZ_init
, XYZ_draw
, XYZ_setPixel
, XYZ_Model3D
etc. Do NOT use the prefix in local variables (inside functions, loops etc.)._
, e.g. _tmpPointerBackup
; with the above mentioned namespace prefix this will look e.g. like this: _XYZ_tmpPointerBackup
.int x = 10, y = 20;
instead of int x=10,y=20;
, write space between if
and its condition etc.getTimeMS
while a variable will be named timeMS
.getCountryTimezone
and getCountryCapital
instead of getTimeZoneOfCountry
, getCapitalOfCountry
etc. This helps with code completion systems. It's not always exactly clear, you may also decide to go for countryGetTimezone
etc., just keep it consistent.camel_case.ext
or nocase.ext
.int a = x;
char b = y;
c += 3 * a;
d -= b;
if (c < d)
a = b;
doSomething(a);
// player shoots
to code implementing player shooting etc.). Use doxygen style comments if you can, it costs nothing and allows auto documentation.#define
s.Here is a short example applying the above shown style:
TODO (for now see LRS projects like Anarch, small3dlib, SAF etc.)
Powered by nothing. All content available under CC0 1.0 (public domain). Send comments and corrections to drummyfish at disroot dot org.