Abstract: There are a lot of benefits to sharing Understand projects, but if you want to create your own, you can still benefit from the shared knowledge of your team.
To share …
With Understand 6.0+ projects, it’s easy to share. The visible .und folder/bundle contains only shareable settings, making it small enough to track with version control. All local data such as absolute paths or which windows you have opened is stored separately. So, what exactly is shared?
- Project settings: this is everything in the project configuration, such as the languages and files in the project.
- CodeCheck Configurations: this contains which validation checks to run and the options for those checks.
- Architectures: custom groups that can be used for metrics, dependencies, and dependency rules.
- Annotations: this lets you share comments with teammates even when you can’t edit the source code.
Creating an accurate project, customizing your CodeCheck configuration, or building an architecture can all be time-consuming tasks. Sharing lets multiple team members benefit from one person’s effort and it’s a great way to keep a team on the same page. Just create the Understand project in your source tree and check it into version control, and your coworkers can benefit from your work.
Or not to share
With all these benefits, of course, we have a shared Understand project for our Understand source code. But the truth is several engineers, including me, don’t use it. What possible reason could there be for that?
One reason is we’ve had our own projects for a while, before sharing projects even became a thing. Why switch when the current system is working? But, the bigger reason is more interesting. We don’t want to share project settings.
Understand source code includes several libraries. Since we aren’t actively editing those libraries, excluding them from the analysis can drastically reduce analysis time while still resulting in a useful project. In fact, the shared project does exclude library code and automatically generated files for that reason.
However, depending on the area you’re working on, you may care about additional files even at the cost of increased analysis time. So, an engineer working on the c++ strict parser may include large libraries that only that parser uses. Personally, I sometimes include web files (when I’m unlucky enough to have issues in that area) or java files (when I’m working on the Java API).
In short, I use my own project because I can add and remove whatever I want from the project definition regardless of what the engineers are looking at.
And how to pretend you’re sharing when you’re not
Even though I don’t want the shared project settings, I do want the shared CodeCheck configurations. This article describes how our team coding standard is set up. I’d rather find and fix my violations before receiving an email about them. To do that, I need to run the shared configuration locally.
The simplest method is copying the shared configuration from shared.und/codecheck/configs/ to mine.und/codecheck/configs/. Personally, though, I symbolically linked mine.und/codecheck to shared.und/codecheck so all configurations will stay up to date.
Architectures and Annotations are also stored in the .und folder, and can be shared with other projects in the same way.
