Code Quality

Ensuring good overall code quality.

Introduction

I insist on code quality — Allen

This means:

No build failures on supported platforms (obviously including our Continuous Integration ("CI") systems)
No compiler warnings allowed using "strict" (strict being a relative term) compiler warning options
No splint issues using -weak checking
No serious Coverity Scan issues
No serious scan-build issues
No Krazy issues
No failed regression tests
Coding Style is very strictly enforced
(A goal) API documentation must be complete
Each source file must have a proper license and copyright header (Krazy tests for this)
Other stuff as I think of it

We want to be as portable as possible. We welcome ports to platforms we haven't encountered previously.

Compiler Warnings

See the top-level CMakeLists.txt for the options we use for each compiler. Expect those options to get stricter over time. Feel free to suggest compiler options that increase our code quality.

Continuous Integration

We use Travis to perform CI for libical on Linux and OSX. For Windows we use the Appveyor CI

Lint Checking

We use Splint for lint checking our source code. I'd love to have lint-checking as part of the CI reporting, but until then we run it by hand and fix the issues as part of the pre-release checklist.

Static Analysis

We're grateful to the good folks at Coverity for giving the FOSS world free access to their wonderful static analysis tool, Coverity Scan. As a goal, I'd like to get the number of Coverity Scan issues down to zero. It might take a few major releases to get there.

scan-build is also good for static analysis checking but I've seen quite some false positives. Good for a free tool, however.

By the way, cppcheck is another tool I like for static code analysis. Occasionally we should run cppcheck as well.

Krazy Analysis

Krazy is another static analysis tool, but it checks mostly for non-C specific stuff, like it ensures Copyrights and License headers, looks for spelling mistakes and also coding style problems. We must be 100% "Krazy clean".

Coding Style

Coding Style is enforced.

API Documentation

We use Doxygen to generate our API Documentation and put the result on our GitHub provided webspace. At this time our API Documentation is horrible and needs a lot of attention (see libical#175), so one of our long term goals is to get the API Documentation into shape with full coverage.