Create contribution guidelines

[juliaschatz]

This file should include

• Style guide reference (Google C++)

• Standards for variable names, documentation amount and location

• Basically take all of the comments you've had about my PRs and put them into one place

Ideally this comes along with a .clang-format file that we can use to format the code to a certain standard and eliminate nitpicky style reviews. We can set up a CI to automatically reject PRs that don't pass the style check.

[JWCS]

We've been using the Google C++ standard for years, and that is the default standard also adopted by ROS. The structures and styles of a node, launch files, and system architecture are bigger, and on my todo list, but idk when I'll have time.

[juliaschatz]

We've been using the Google C++ standard for years, and that is the default standard also adopted by ROS.

Is this written anywhere? Because I didn't know this until literally just now.

[JWCS]

Sorry for the late response. Yes, we've been using it for the last few years, and it is a kind-of (tongue-in-cheek) standard, fighting between the different prevailing styles. It is also said in the ros wiki, for it specifically, however the ros wiki also contains code (and formatting suggestions) from before the google standard consideration was widespread, coming from the initial willow garage pr2 robot project. Note, this is different than C, there isn't so much a public standard for C as much as several strong community style preferences, safety-compliance style requirements, and several big companies whose preferences have dominated the scene. (Incidentally, I noted, reading the RT repo, that there are some quality of life improvements to be made, to make it safer/better/more akin to industry). (I'm probably your best reference on safety-critical RT embedded C development). I cannot explain why you were unaware of it, but perhaps between the other on-boarding trainings, it was pushed off. As you've noticed, not many are quite producing as much code as you are (kudos). As I've said before, there are three things to learning ros: the ros middleware (easy), the ros ecosystem (time-consuming), and ros project management (which is a mixture of beating off bad practices that have become ingrained in some long-running projects' api's, learning how bad some patterns are, and not being lazy (that one is really hard, b/c not paying for it now sounds cheaper than paying for it later)).