Coding standards?

[KurtEck]

Was wondering if we should try aiming toward some form of coding standards. Personally I don't think we need to go overboard here, but a few things might be nice. Hopefully I am not kicking a hornets nest

One standard I know some are semi following now is that for ROS: http://wiki.ros.org/CppStyleGuide
Which might be nice to get to, but it might take a bit to get there.

In the mean time, there are some simple things we might want to think about, like:

End of lines - My last edit of a few of the files showed up like I changed every line. Turns out the file was previously saved with every line ending in <CR><LF> (Windows) where my updated file ended with only <CR> (Linux). Preference? Mine is currently set for Linux as that is what some other projects wanted...

Spacing - Tabs versus spaces? How much to indent. I know lots of us have different preferences. Personally I prefer indenting by 4... I know others like by 2... I know some of the current files are done with spaces others with tabs...

Code blocks - Where to put the brackets?

    if () {
    }

    if ()
    {
    }

    if ()
        {
        }

Personally I can go anyway. My least favorite is the third one, and over the years I have alternated between the first two depending on the project.

Where things start to get tricky are with things like naming conventions. Which is probably something for follow on discussions.

Thoughts?

Kurt

[tician]

I've not really been consistent in my projects about naming conventions, but whenever possible I exclusively use 'braces on their own lines indented same as previous line' and literal tab characters (user's editor of choice can then expand tab into 2, 4, 6, 8, etc. as desired or do simple find-and-replace if they just have to have spaces). I've also been using the linux line termination exclusively for several years as I've been using only linux for my computers and there are some programs that even when run on windows really do not like the windows line termination.

[KurtEck]

Thanks Tician,

Yep - I also prefer the braces on their own lines, but have alternated on different projects to have the { on same line as on some projects had people complaining that the other way takes up too many lines so you can not see much code...

Likewise with tabs versus non-tabs and spacing... Many arguments over the years.. So I try to go with flow... Things like yes with tabs, each user can use their own preferences for how many show up on display, which works well for start of line, but when users do things like tabs inside lines to line up things (like member variable names), they only line up properly for the same tab setting... But again I would simply like to go with the flow...

One things I do like to do is to do things like remove compiler warnings. Back in my previous life, there used to be rules you could not check in code that had warnings, which sort-of stuck with me. Earlier I made a pass to remove most/all of them, but as more code is being integrated in, like the streamer code, I seeing more of them. So yesterday did a pass through some of the stuff again and put a partial update for this in my working branch (once done, may see about making it into a pull request..)

Some of them I have not fixed yet, for example in dxl_monitor, complains that function gets is not safe... So will probably convert to fgets, which you pass in buffer length... But will have to change code a little as \n will be part of buffer...

Note some of the fixes I did to remove warnings are good things, like change some of the functions and or methods, to "const char *" instead of simply "char *". This removes warnings if you try to set the pointer to Quoted character strings, like: ptr = "Text"
But some of the changes were sort of superficial, like when the code is not checking the result of a function. Example:

write(fd, buffer, strlen(buffer));

The change I did removes warning, but still does not check:

int res __attribute__((unused));
  res = write(fd, buffer, strlen(buffer));

Again it would probably be better to actually do something with the result, maybe simply assert, or ...