yade-dev team mailing list archive

[Anton Gladky <gladky.anton@xxxxxxxxx>]

Hi Bruno,

2014-07-17 14:35 GMT+02:00 Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>:
> So maybe a minimal consensus that we could put somewhere in the doc
> could be: braces styles 1,2,3,4 depending on what's inside the braces.
> In addition:
> * indent, and indent consistently, spaces OR tabs in the same file (I
> would like tabs everywhere but not all editors can do that automaticaly
> and maybe no consensus on this), if spaces at least four for each
> indentation level

I am personally prefer 2 spaces as indent, but I am not an indent-nazi at
all. Important is to keep an existing indent during file edition [1].

> Tabs can be a different size on different computers and printers.
> The code might look great on the original computer, but on another
> computer or printout the spacing might look all weird.
> With spaces, the code will look the same regardless of the computer.

[1] http://stackoverflow.com/questions/11492179/tabs-vs-space-indentation


> * don't run autoformating and don't re-indent large blocks if not the
> main author of one file, and if you really do so make a special commit
> stating explicitely that it is a formatting commit.

Agree, large autoformatting updates should be avoided.

> 1*If a block has a single statement, no braces:
> if () doSomething;
> else somethingElse;
>
> 2*if multiple but very short statements:
> if () {a=1; b=2; c=3;}
>
> 3*for more complex blocks:
> if (){
>         longStatement1;
>         longStatement2;}

If you mean a "google code style" but it looks like:

if () {
  longStatement1;
  longStatement1;
}

I do usually use this one.

> 4*for even longer blocks:
> if ()
> {
>         longStatement1;
>         ...
>         longStatementN;
> }

IMHO, the previous or this one are almost the same,
no need to duplicate them, just choose one.

> 5* avoid closing brackets on the same line:
> if () {
>         for () {
>         }}
>
> Comments?

I think, we can take like a base an existing code
convention (like this a simple one [2]) and just use it.

The most important is always to think about the people
who will read your code and possibly fix bugs in it. The code
should not be too complicated, the line should not be too long.

[2] http://codeketchup.blogspot.de/2013/05/simple-and-basic-c-coding-conventions.html

Regards

Anton