Be liberal in what you accept (nw)

master
Olivier Galibert 2015-05-18 09:48:29 +02:00
parent 63e7d59f41
commit 4257a83cb7
1 changed files with 1 additions and 67 deletions

View File

@ -57,70 +57,4 @@ Contributing
MAME source code should be viewed and edited with your editor set to use four spaces per tab. Tabs are used for initial indentation of lines, with one tab used per indentation level. Spaces are used for other alignment within a line.
Try to follow these rules to help keep the code consistent and readable:
* Indent code one level for each level of scope
* Don't indent for things that don't change the level of scope (e.g. case labels)
* Outdent labels (including case labels) by one level
* Indent line continuations by a different amount to a level of scope so they can be visually distinguished
* Place the braces that open and close compound statements on their own lines to make them easier to visually balance (with the exception of compound statements on a single line)
* Don't visually separate parts of an if/else tree with comments or whitespace, compound may help tie things together
* If one branch of an if/else tree requires a compound statement, use compound statements for all branches
* Wrap macros in do/while to make them play nicer with surrounding code
* Use parentheses when using macro arguments to make semantics more predictable
Here's an example showing many of these things:
```c++
#define SOME_MACRO(a, b) do { something((a) * (b)); } while (0)
bool function(
int intparam,
long longparam)
{
switch (intparam)
{
case val1:
case val2:
{
bool scoped(initialisation());
call_something(scoped);
}
break;
case val3:
unscoped_call(longparam);
break;
default:
goto failure;
}
if (cond1) { trivial(); stuff(); }
else { also(); trivial(); }
if (cond2)
{
// The compound statements braces guide you to the next part of the tree
something();
}
else if (cond3)
{
another_call();
}
else
{
the_default();
}
many_params(
first(),
second(),
third(
also(),
has(),
several()),
fourth());
return true;
failure:
return false;
}
```
Some parts of the code follow GNU style, some parts of the code follow K&R style, mostly depending on who wrote the original version. Above all else, be consistent with what you modify. For new code, the majority tends to prefer GNU style, so if you don't care much, use that.