Initial code style proposal

[antoniovazquezblanco]

Reading the code I found a couple of different code styles. I would like to unify them and provide a clang-format file to avoid future deviations.

If you provide any feedback I will try to follow whatever style request you make.

Thanks

[antoniovazquezblanco]

Aaaaand it breaks... :man_facepalming:

Sorry, while I fix it, send feedback about the idea..

Thanks!

[BatchDrake]

Hey, thanks for the PR. There is indeed a coding style that in the early times (i.e. sigutils) was somewhat inconsistent. Nonetheless, I am skeptical about automatizing it with clang. Basically because there are certain purposefully ambiguous rules that end in "whichever is more readable".

Since this rules are a lot, and unfortunately I never spent time writing them down, I believe it is better off to unify the styles incrementally, as this list is formalized somewhere. The most straight-forward to apply are:

1. 2 space indentation (never-ever use tabs)
2. Max number of columns is 80
3. No space before parenthesis except for flow control statements (if, for, switch, etc) and sizeof
4. Opening and closing braces in the same line as the statement they refer to, preceded by a space (if () {) except for function definitions (opening braces in a new line)
5. Variable declarations at the beginning of the innermost block they are required.
6. Return type and qualifiers of a function prototype goes in the same line as the function name.
7. Return type and qualifiers of a function definition goes in two separate lines (qualifiers, types, line break, name(...))
8. If a line is too long (more than 80 chars) we break it according to the following rules:
   • We break from left to right, until all sublines honor the 80 column limit
   • Line break increments the indentation level of all sublines in one unit (2 spaces) except the first one
   • Unary operations are never broken
   • Binary operations are broken between the first operand and the operation
   • Ternary operations are broken in three lines, with the first break between the conditional expression and the "?", and the second break right before the ":"
   • Function calls are broken right after the parenthesis, with every argument in a separate line except if the grouping of certain arguments improves readability (e.g. pairs of I/Q components, groups of 3 spatial coordinates, etc)
   • Function definitions are broken right after the parenthesis, with every argument definition in a separate line, always.
9. Assignments inside conditional statements are allowed, unless it impacts readability
10. Braceless blocks (i.e. when the body of certain control flow statement consists in only one statement) are preferred, according to the following rules:
    • The statement itself and its body is separated by a line break, with the body indentation incremented by one unit.
    • If the statement is an if-else construct, and one of either blocks contain more than 1 statement, both blocks use braces.
    • If the statement consists of several nested blocks of the same kind, and any of the statement bodies cannot be expressed as a braceless block, all nested blocks use braces.
11. Variable names in declarations are not aligned, unless it improves readability.
12. Structure member names are not aligned, unless it improves readability.
13. Pointer declarations leave a space between the type and the stars, and no space between the stars and the identifier, or between the stars themselves.
14. In C code, we favor lower snake case for variables, types and function names.
15. In C/C++ code, we favor upper snake case for #defines and enumerated constants.

[antoniovazquezblanco]

From your feedback I believe that we might not be able to fully write down this into clang-format rules.

Given this you may prefer to avoid using a formatting tool at all. Maybe flexing them in order to automate formatting is ok with you.

Let me know whatever you prefer regarding this matter...

[antoniovazquezblanco]

Tryed to create a clang-format config file that conforms to this rules... Hope this is a little better than before :)

[BatchDrake]

This looks way better than before. If you manage to indent #ifdef / #if / #endif directives (with spaces between # and the directives) I'll merge right away.

[antoniovazquezblanco]

:)

[antoniovazquezblanco]

Thanks!