Our code is inconsistently styled

[squarewave]

We need to settle on some conventions for code style. I still like google's style conventions, but I'm willing to change, I just think we should agree on something soon.

There's of course the issue that libraries we're consuming don't follow google's style conventions, but I suspect they're all different enough that we would have inconsistencies from third-party libraries no matter what. I think in some cases we're really using very little of these arduino libraries and it would be nice to just rewrite what we need.

Anyway, I don't have strong opinions yet, I just think we should get the conversation started.

[squarewave]

Another point that should be made, if we use google's code style we can just pull in their cpplint.py tool for validating code style and we (hopefully) wouldn't have to fiddle with it much.

[dashed]

Totally recommend this: http://astyle.sourceforge.net/astyle.html

[squarewave]

Oh, that's awesome!

[davidsthayer]

BTW - Recent discussions leaning toward GitHub auto versioning not being our best option. Let's set a standard that we version up each incremental change manually in comments. Anyone weigh in on this? Doug?

[squarewave]

Er, we should just be using tagging to version things. use semantic versioning to determine your version number and tag your commits like this:

git tag -a v0.2.1

Which will open up a text editor to leave a longer message. We should probably talk about what we want that message to look like, though. If we sufficiently comment our commits it's perhaps unnecessary. We could also use lightweight tags which don't require a message.

[squarewave]

It's tricky because there's plenty of established ways to go about git branching and tagging and things like that, but they're all tailored to big application development. I think maybe it just makes the most sense to use lightweight tags, because all we really want from it is an alias for a commit. To do a lightweight tag, just use something like

git tag v0.x.y

[dashed]

I can vouch for semver having use it a lot for node.js development. Though, it seems unusual for a C++ project, and haven't seen anyone using it in C++ projects in the wild.

semver is not without its imperfections. Some authors of popular JS libraries have expressed criticisms of semver once you go beyond v1.x.y, and arguing for the un-human-like communication of incrementing the major version. In other words, reaching v222.x.y when making a lot of incompatible API changes. Incrementing major version may lead others to think something big happened.

Others have argued that it wouldn't matter; giving Chrome's versioning semantics as an example (version 30+).

If you do decide to use semver, ensure to note that source code follows this version semantics; like in the README.

[squarewave]

I kind of think C++ coders are just not a very community-ish community by today's open source standards, and thus don't really have strong norms for these kinds of things. In either case though for the time being it's just a way of keeping track of development in our heads. And yeah that's a good call about noting that in the README. I think in the next few weeks we should generally be thinking about documentation at all levels, though.

[jacobbenlewis]

Ug. I'm having a hard time getting motivated to implement the google standard as I read through it. Hopefully using a tool like astyle mentioned above will do the trick. I know we have to pick a standard and go with it, and I'm resigned to going with Google's, but I have to whine just once that I can't stand 80 character line limits, brackets on the same lines as function definitions, and underscores in most any case.