Difference between revisions of "Coding style/Style checker"

Revision as of 16:05, 4 October 2012

The krb5 source tree includes a Python script to check for some C style issues which might be introduced by a change. The style checker script is not comprehensive. Even if it reports no output, a reviewer may still note code style issues related to the change. Conversely, the script may report false positives or issues which should not be fixed. For instance, if a file makes extensive use of parenthesized return statement (such as in the mechglue or other code originating in Solaris), it is better to adhere to that file's style than to use a non-parenthesized return statement just to placate the checker. Nonetheless, using the style checker and intelligently interpreting its output will usually reduce the time needed to integrate a change into the MIT krb5 tree.

Using the style checker with git

If you are using git, you can run the diff checking script from anywhere in the working tree:

   python /path/to/src/util/cstyle.py [-w] [rev|rev1..rev2]

By default, the script checks working tree against HEAD, or checks changes in HEAD if the working tree is clean. With a revision argument, the script checks changes in rev or the series rev1..rev2. With the -w option, the script checks the working tree against rev (or against HEAD by default). Only C style issues occurring in lines introduced by the diff(s) will be reported.

You can also set up a hook to automatically run the checker every time you locally commit a change. To do this, put the following into your working tree's .git/hooks/post-commit and make that file executable:

   #!/bin/sh
   
   python src/util/cstyle.py HEAD

If the checker reports issues which can be fixed, you can easily fix them and run "git commit -a --amend" to amend the commit before pushing it upstream.

Using the style checker without git

If you are not using git, you can use the per-file checker:

   python /path/to/src/util/cstyle-file.py filename

but this may report existing style issues in the source code as well as issues introduced by your changes. Do not clean up existing style issues as part of a change.