[ODE] Code quality

[Remi Ricard]

Hi Bram,

 > People,
 > I'm with Jon on this....
 > I see no benefit in enforcing a style.
 > As long as the style is consistant *within a single file*, and the 
indentation matches the program logic, who cares...?

The problem is the fact that even in a single file the style is not 
consistant.

I tried several time to configure emacs to display a nice indented code 
and when I open a new file it is a big mess. Sometime there is tab 
sometime it is space (2 or 4 or even 8 space) all in the same file.

 > Different sections of the code have different main-contributors, as 
soon as
 > we start beautifying the code, we get a much harder time doing diffs.

If we set a standard it will be easier for people (like me) to submit a 
patch and not disturb too much the code. The submitter does not have to 
dig in the different files to try to find the coding style used by the 
ODE code base.

 >
 > What if we were to diff a beautified GIMPACT against a new GIMPACT 
release?
 > Absolute mess!

There will be only one mess. The first time the patch is apply.
Then after that there will be no mess.

Since in the "set the style patch" there will be no code change merging 
should not be a big problem.


 > I already get this when diffing a fixed Ctrl-M file.

This should be solved by using SVN. I know CVS did know the difference 
but I think SVN can always save in unix or DOS or whatever end of line 
format.

 >
 > Coding style does *not* equate code quality, as stated earlier in 
this thread.

I still agree with that it only make the code easier to read

 > More unit tests would help code quality.

I agree also.

I patch should include a test with it.


 > But these tests should be close to the source code, and not in a
 > separate dir. The source file that solves ray-vs-sphere should include
 > a test section that tests boundary cases of this problem.

Maybe not in the same directory but easy to access.
My main concern is to have a setup where it is easy to create new tests
and easy to run the tests.

Having a better "how to" on how to create and submit a patch.

It can also be written that a patch with a test will have more change to 
be accepted and included in the source code.



Remi