Development > Newbie Coding

New Auto Mission code proposal

<< < (2/3) > >>

Destructavator:
OK, here's a little more work, a few additional functions, and a .c file in addition to the header for some complex math functions.

I tried to conform to the code guidelines for the project - How do these look?  If I were to code the actual auto-mission code like this (which I'll start very soon), would this be OK?

Please note I didn't actually try to compile these.

Destructavator:
Oops!  In that last 7zip file I put the old version of the header in with the newer .c file, by accident.

Sorry about that, give me a few minutes and I'll attach the proper, updated files.

Edit:  OK, here they are.  I also added some more comments to give a better idea of what the hey is going on in parts of the functions.

Edit #2:  Hmmm...  I did a little reading on C vs C++, and it appears I have more "homework" to do on the differences.  Sorry, I've never worked in regular C before, my bad.

geever:

--- Quote from: Destructavator on April 05, 2011, 09:28:05 pm ---Oops!  In that last 7zip file I put the old version of the header in with the newer .c file, by accident.
Sorry about that, give me a few minutes and I'll attach the proper, updated files.

--- End quote ---

- First of all, please check your editor, the patch contains 4spaces per level instead of TABs in indentations.

- Second comments: there are two different kind of comments we use:
a) doygen:
/**
 * @brief what this function does
 * @param[in] param1  What is param1
 * @param[in,out] param2 What is param2
 * @return @c true if blabla...
 */

Always write doxygen comments for functions, our documentation is made of them automatically. (We also make doxy for macros/constants/structures which are not obvious)

b) normal comments
there is no asterisk leading for a normal comment
put normal comments in separate line if possible

- function signatures: put a space between function name and parameter list in the .c file but not in the .h file.
- if and the (condition) should also have a space between.

Wrong whitespace using will FAIL the pushing of the commit. We have some automatic tests for whitespace rules.

- I suggest using double precision types for the parameters

- I lost in the bracket jungles of macros in the header file, also in macros every parameter should be protected with brackets as they can be complex expressions on calling. (we agreed that they'll be better as inline functions)

- better parameter (and function) names if possible, please

- make the functions failsafe, now they can easily div by zero. If the parameters domain are strict you should explain it in the @param doxygen tag, and can check with at least an assert().

- there are much comments in the .h I don't get, can you clean them up? Or I should have some drink, to make it clear? :D

-geever

Mattn:
Please also make sure to provide aunittest. I will prepare the files for you once i have the time.

Destructavator:
This isn't totally finished, but how does this look?

Navigation

[0] Message Index

[#] Next page

[*] Previous page