proxmark3/HACKING.md

274 lines
7.7 KiB
Markdown
Raw Normal View History

2019-05-05 06:41:20 +08:00
_"Coding styles are like assholes, everyone has one and no one likes anyone elses."_
--Eric Warmenhoven
# Overview
The Proxmark3 codebase is pretty messy and in the process of being cleaned up,
so we don't have clear guidelines on how to place new code just yet. However,
please don't make things worse.
However, we have established a set of coding style guidelines in order to
2019-03-12 06:11:26 +08:00
clean up the code consistently and keep it consistent in the future.
Look around and respect the same style.
2019-05-05 06:41:20 +08:00
2019-03-12 06:11:26 +08:00
Helper script to get some uniformity in the style:
2019-05-05 06:41:20 +08:00
`$ make style`
2019-05-05 06:41:20 +08:00
It makes use of `astyle` so be sure to install it first.
2019-05-05 06:41:20 +08:00
# Indentation
2019-03-12 06:11:26 +08:00
Don't use tabs, editors are messing them up too easily.
Increment unit is four spaces.
2019-05-05 06:41:20 +08:00
If you use `make style`, this will be done for you.
2019-05-05 06:41:20 +08:00
# Width
Try to keep lines to a reasonable length. 80 characters is a good mark; using an
editor that shows a vertical line is a great idea. However, don't break a line
just because you're slightly over, it's not worth it. No 200-character lines,
though.
2019-05-05 06:41:20 +08:00
# Macros
2019-05-05 06:41:20 +08:00
`#define`, function-like or not, are all UPPERCASE unless you're emulating a
well-known function name.
2019-05-05 06:41:20 +08:00
# Identifiers
Functions, local variables, and arguments are all named using
2019-05-05 06:41:20 +08:00
`underscores_as_spaces`. Global variables are Evil and are prepended with `g_` to
distinguish them. Avoid them.
Single-character variables are a bad idea. Exceptions: loop iterators and maybe
2019-05-05 06:41:20 +08:00
simple byte pointers (`*p`) in very obvious places. If you have more than one
such pointer, use a real name. If you have more than a couple nested loops,
complex logic, or indices that differ in interpretation or purpose, use real
names instead of i,j,k.
2019-05-05 06:41:20 +08:00
# Data types
2019-05-05 06:41:20 +08:00
Use `stdint.h` types (`uint32_t` and friends) unless you have a reason not to. Don't
use microsoft-style `DWORD` and the like, we're getting rid of those. Avoid char
for buffers, `uint8_t` is more obvious when you're not working with strings. Use
`const` where things are const. Try to use `size_t` for sizes.
2019-03-12 06:11:26 +08:00
Pointers and reference operators are attached to the variable name:
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
void *ptr;
2019-05-05 06:41:20 +08:00
```
not:
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
void* ptr;
2019-05-05 06:41:20 +08:00
```
otherwise you're tempted to write:
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
void* in, out;
2019-05-05 06:41:20 +08:00
```
and you'll fail.
2019-05-05 06:41:20 +08:00
`make style` will take care of pointers & reference operators.
2019-03-12 06:11:26 +08:00
2019-05-05 06:41:20 +08:00
# Expressions
In general, use whitespace around binary operators - no unspaced blobs of an
2019-05-05 06:41:20 +08:00
expression. `make style` will take care of whitespaces around operators.
2019-03-12 06:11:26 +08:00
For example,
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
if (5 * a < b && some_bool_var)
2019-05-05 06:41:20 +08:00
```
but not
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
if (5*a<b&&some_bool_var)
2019-05-05 06:41:20 +08:00
```
For equality with constants, use `i == 0xF00`, not `0xF00 == i`. The compiler warns
you about `=` vs `==` anyway, and you shouldn't be screwing that one up by now
anyway.
2019-05-05 06:41:20 +08:00
# If / for / while etc
2019-03-12 06:11:26 +08:00
Put the opening brace on the same line, with a space before it.
There should be a space between the construct name (if/for/whatever) and the
opening parenthesis, and there should be a space between the closing parenthesis
2019-03-12 06:11:26 +08:00
and the opening brace, and no space between parenthesis and expression.
2019-05-05 06:41:20 +08:00
`make style` will take care of all that.
2019-03-12 06:11:26 +08:00
If you do split the condition, put the binary operators that join the lines at
the beginning of the following lines, not at the end of the prior lines.
2019-05-05 06:41:20 +08:00
For generic `for()` iterator variables, declare them in-line:
```
2019-03-12 06:11:26 +08:00
for (int i = 0; i < 10; i++) {
...
}
2019-05-05 06:41:20 +08:00
```
Note the spaces after the semicolons.
if/else should be laid out as follows:
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
if (foo) {
...
} else if (bar) {
...
} else {
...
}
2019-05-05 06:41:20 +08:00
```
You can skip braces around 1-line statements but don't mix braces vs. no braces.
2019-05-05 06:41:20 +08:00
# Functions
2019-03-12 06:11:26 +08:00
Put the return type on the same line.
Put a space after a comma in argument lists.
Open the brace after the declaration (after a space).
2019-05-05 06:41:20 +08:00
`make style` will take care of all that.
```
2019-03-12 06:11:26 +08:00
void foo(int a_thing, int something_else) {
...
}
2019-05-05 06:41:20 +08:00
```
Functions with no arguments are declared as `f(void)`, not `f()`.
2019-03-12 06:11:26 +08:00
Use static for functions that aren't exported, and put exported functions
in a header file (one header file per source file with exported functions
usually, no huge headers with all functions).
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
void baz(void) {
foo(bluh, blah);
}
2019-05-05 06:41:20 +08:00
```
Function names should be `separated_with_underscores()`, except for standard
functions (`memcpy`, etc.). It may make sense to break this rule for very common,
generic functions that look like library functions (e.g. `dprintf()`).
2019-03-12 06:11:26 +08:00
Don't use single-character arguments.
Exception: very short functions with one argument that's really obvious:
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
static int ascii(char c) {
if (c < 0x20 || c >= 0x7f)
return '.';
else
return c;
}
2019-05-05 06:41:20 +08:00
```
vs.
2019-05-05 06:41:20 +08:00
```
2019-03-12 06:11:26 +08:00
static void hexdump(void *buf, size_t len) {
...
}
2019-05-05 06:41:20 +08:00
```
2010-02-22 03:58:32 +08:00
As a general guideline, functions shouldn't usually be much more than 30-50
lines. Above, the general algorithm won't be easily apparent, and you're
probably missing some factoring/restructuring opportunity.
2019-05-05 06:41:20 +08:00
# Structs / unions / enums
Use typedefs when defining structs. The type should be named something_t.
2019-05-05 06:41:20 +08:00
```
typedef struct {
2019-03-12 06:11:26 +08:00
blah blah;
} prox_cmd_t;
2019-05-05 06:41:20 +08:00
```
You can use anonymous enums to replace lots of sequential or mostly-sequential
#defines.
2019-05-05 06:41:20 +08:00
# Switch
2019-05-05 06:41:20 +08:00
Indent once for the `case:` labels, then again for the body. Like this:
```
switch(bar) {
2019-03-12 06:11:26 +08:00
case OPTION_A:
do_stuff();
break;
case OPTION_B:
do_other_stuff();
break;
}
2019-05-05 06:41:20 +08:00
```
`make style` will take care of the indentation.
2019-03-12 06:11:26 +08:00
If you fall through into another case, add an explicit comment;
otherwise, it can look confusing.
2019-05-05 06:41:20 +08:00
If your `switch()` is too long or has too many cases, it should be cleaned up.
Split off the cases into functions, break the switch() into parent and children
switches (e.g. command and subcommand), or use an array of function pointers or
the like. In other words, use common sense and your brain.
If you need local scope variables for a case, you can add braces:
2019-05-05 06:41:20 +08:00
```
switch(bar) {
2019-03-12 06:11:26 +08:00
case OPTION_A: {
int baz = 5 * bar;
do_stuff(baz);
break;
}
...
2019-05-05 06:41:20 +08:00
```
But at that point you should probably consider using a separate function.
2019-05-05 06:41:20 +08:00
# Comments
Use //, it's shorter:
2019-05-05 06:41:20 +08:00
```
// this does foo
...
// baz:
// This does blah blah blah .....
// blah blah...
2019-05-05 06:41:20 +08:00
```
`/* */` can be used to comment blocks of code, but you should probably remove
them anyway - we have version control, it's easy to fetch old code if needed,
2019-05-05 06:41:20 +08:00
so avoid committing commented out chunks of code. The same goes for `#if 0`.
2019-05-05 06:41:20 +08:00
# File
2010-02-22 03:58:32 +08:00
2019-05-05 06:41:20 +08:00
Please use common sense and restrain yourself from having a thousands line
2010-02-22 03:58:32 +08:00
file. Functions in a file should have something *specific* in common. Over time
sub-categories can arise and should therefore yield to file splitting.
2019-05-05 06:41:20 +08:00
For these reasons, vague and general filenames (e.g. `util.*`, `global.*`, `misc.*`,
`main.*`, and the like) should be very limited, if not prohibited.
2010-02-22 03:58:32 +08:00
2019-05-05 06:41:20 +08:00
# File headers
License/description header first:
2019-05-05 06:41:20 +08:00
```
//-----------------------------------------------------------------------------
// YOUR COPYRIGHT LINE GOES HERE
//
// This code is licensed to you under the terms of the GNU GPL, version 2 or,
// at your option, any later version. See the LICENSE.txt file for the text of
// the license.
//-----------------------------------------------------------------------------
// FILE DESCRIPTION GOES HERE
//-----------------------------------------------------------------------------
2019-05-05 06:41:20 +08:00
```
If you modify a file in any non-trivial way (add code, etc.), add your copyright
2019-03-12 06:11:26 +08:00
to the top with the current year.
2019-05-05 06:41:20 +08:00
# Header files
Use the following include guard format:
2019-05-05 06:41:20 +08:00
```
#ifndef FOOBAR_H__
#define FOOBAR_H__
...
#endif // FOOBAR_H__
2019-05-05 06:41:20 +08:00
```
Keep in mind that `__FOOBAR_H` would be reserved by the implementation and thus
you shouldn't use it (same for `_FOOBAR_H`).
2019-05-05 06:41:20 +08:00
# Whitespace
2019-03-12 07:11:27 +08:00
Avoid trailing whitespace (no line should end in tab or space).
Keep a newline (blank line) at the end of each file.
2019-03-12 07:11:27 +08:00
2019-05-05 06:41:20 +08:00
`make style` will take care of both.