This is the thirteenth post in my SCons series.
In the previous episode I integrated Protoc, an existing custom builder, in my SCons project.
This post will demonstrate how this builder fails with non-trivial projects, and suggest some fixes and improvements.
I wanted to share my proposed fix via the SCons wiki page, but I couldn’t create a user… I’d appreciate if someone with access to that wiki could assist 🙂 .
The final result is available on my GitHub scons-series repository.
This is the twelfth post in my SCons series. This posts continues exploring ways to work with protocol buffers in a SCons project.
In the previous episode I covered the manual approach to using protocol buffers in a SCons project. As mentioned there, SCons does not know how to compile .proto files into C++ and Python code out of the box.
This post will take the integration a step further, by actually using SCons to compile .proto files.
I am definitely not the first one to suggest this SCons extension. I started using the SCons ProtocBuilder by Scott Stafford. It worked fine for my needs, until it didn’t. This post focuses on integrating Scott’s builder as is. Future posts will deal with fixes and improvements.
The final result is available on my GitHub scons-series repository.
This is the eleventh post in my SCons series. This post starts exploring ways to work with protocol buffer files in a SCons project.
Protocol buffers are a structured-data-serialization mechanism from Google. This is not a tutorial on protocol buffers. I will use the address book project example that appears in the official protocol buffers tutorial.
When using protocol buffers, you write .proto files to describe your structured data. You use the protoc compiler to generate C++ and Python code that allows you to serialize, load, and manipulate your protocol buffers data.
Out of the box, SCons does not know how to compile .proto files into C++ and Python code. The purpose of this post is to start exploring ways to integrate protocol buffers in the build process. The first iteration is based on manual “integration”.
The final result is available on my GitHub scons-series repository.
The Google C++ Style Guide defines a guideline for names and order of includes. It occurred to me that grouping and sorting include files is tedious and error prone, and a computer can do it much better. So I wrote a script that does exactly that 🙂 .
The nitpick script is available on my GitHub cpplint fork.
If you’re comfortable with Python, you can figure out the script straight from nitpick.py source code and the accompanying unit tests. You can also read the rest of the post for some plain English review 🙂 .
The Google C++ Style Guide defines a guideline for names and order of includes. Unfortunately, the cpplint tool that automates style-guide checking isn’t consistent with that guideline, as far as “other libraries h files” are concerned.
In this post, I demonstrate the claimed inconsistency, and suggest an enhancement to cpplint to fix the inconsistent behavior.
The enhancement is available on my GitHub cpplint fork (including addition unit tests).
cpplint is an automated checker for C++ code. It checks the style of an input C++ source file against Google’s C++ style guide.
If you’re writing C++ code, and trying to follow the said style guide, I strongly recommend using this tool!
Endless rants can be written on programming style and style-guides. This is not one of them 🙂 .
At the end of the day, my personal opinion is that it doesn’t really matter what conventions you choose to follow. What does matter is that if you collaborate with a team on a common codebase, it’s extremely important to obtain and sustain consistency. To that goal, as long as one consistent style guide is followed by all collaborators – the specifics of the style guide are not too important.
When choosing a style guide to follow, having an automated tool available for collaborators to check themselves has great value. Without it, code reviews end up revolving around style issues instead of the logic being reviewed (you are practicing code reviews, right?). This is the main reason that I default to Google’s C++ style guide.
One of the things I like most about Google’s cpplint tool is that it prefers false negatives over false positives. This means that, while it misses some “style issues”, it usually doesn’t mistakenly produce warnings for compliant code. From my experience, developers are quick to ditch tools that generate lots of cruft. It’s much better that the developer fixes some reported issues instead of ignoring all.
The cpplint tool is available on this official Subversion repository, as well as from my GitHub fork of it. I forked it to make some changes. They might be specific to how I work, but maybe others may benefit from them. Checkout the cpplint tag for more on my changes and other cpplint-related stuff. See also the google-styleguide project.
More coffee == more content!
The Ostrich by Itamar Ostricher is licensed under a Creative Commons Attribution 4.0 International License.