TICS User Guide

Command Line Interface

The TICS client is used to check the quality of your code before committing (or pushing) it to the repository. You invoke the TICS client from the command-line as follows:

TICS [ @ ] { input } ... [ -- { compiler options } ]

Passing the files to analyze to TICS

Examples of TICS calls are TICS xyz.cpp abc.c and TICS @xyz.vcxproj. The TICS executable accepts multiple files as arguments (including wildcards in directory and file names). It can also process a list of input files from a file list. This is achieved by prefixing the file list with an "at" symbol '@', e.g., TICS @Address.lst. It is not allowed to nest file lists.

For an example of how to use file lists in the TICS context, see this use case.

Using wildcard parameters in the file argument, like everything/in/my/directory/*, is discouraged. This is because some shells (among which Bash and the Windows command line prompt) already resolve these wildcard parameters before starting TICS, and pass the resolved parameters to TICS rather than the wildcard as is. As such, if you use wildcard parameters, you may not be passing the command line arguments to TICS that you are expecting - resulting in unexpected behavior.

Note also that the client will check against the ARCHIVE.txt file(s) unless a list of source files is directly passed to the client, for instance TICS src1.cpp src2.cpp src3.cpp. If it however contains any containers (for instance a file list or a directory) then then the ARCHIVE.txt will be used.

Further filtering on the set of input files can be done by using the -language parameter. For instance, if you are checking the contents of a large directory but are only interested in the Python code, you can use the parameter -language PYTHON to filter out all non-Python files.

When the ARCHIVE.txt is used by the TICS client and different code types are specified within the ARCHIVE.txt file, the default behaviour of the TICS client is to exclude all files that are not marked as production code. If you still want to analyze files that are not production code, the following ways are available to do so:

passing all files as an explicit argument to TICS. This ignores any checks on whether a file should be analyzed such as ARCHIVE.txt and code type checks. TICS assumes that if you explicitly pass a file, you want to analyze the file.
using the -ignorefilters command line option which will cause TICS to ignore the contents of the ARCHIVE.txt file.
using the -codetype argument, which allows you to pick which specific types of code you want to analyze with the TICS client.

For some other options regarding filtering the list of files that TICS analyzes, you can check out use cases how to control the TICS analysis set.

Passing compiler options

When the -- option is used, all following options will be passed to the compiler. The -- option helps to use TICS as a compiler replacement in makefiles.

Configuring the TICS Client

It is possible to configure TICS via a graphical user interface named TICSConfig. Documentation for how to use TICSConfig can be found here.

Options available for TICS Client

See this page for a list of all possible options for the TICS Client.

Violation Suppression

It is possible to suppress individual violations. Suppressing a violation can be done by using special comments in the code. These special comments start with //TICS or /*TICS. A space is allowed after the comment marker. Example:// TICS or /* TICS. After the preceding //TICS or /*TICS one can specify what rules are suppressed by means of a sequence of -ruleid statements. E.g.

//TICS -OBJ_16 -DCL_12
// TICS -OBJ_16 -DCL_12

The rules specified in the TICS violation suppression comment are suppressed for the remainder of the file, starting at the line that contains the comment. The comment has file scope, i.e., it will not apply to included files or enclosing files. It is allowed to use wildcards to specify rules. To switch on a rule again, one can use "+ruleid" statements. It is also possible to suppress a rule of only one specific source line. This is possible with the option "!ruleid". Anything past whitespace or past either one of the special characters : , \ is treated as a comment.

The following example shows how this facility can be used in practice.

//TICS -OBJ_?: TODO still need to be fixed after discussion
// MainFrm.cpp : implementation of the CMainFrame class
//

#include "stdafx.h"
#include "test.h"

#include "MainFrm.h"

#ifdef _DEBUG
#define new DEBUG_NEW      //TICS !OSD_3:  AppWizard generated code
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

/////////////////////////////////////////////////////////////////////////////
// CMainFrame

IMPLEMENT_DYNAMIC(CMainFrame, CMDIFrameWnd)

//TICS -*: AppWizard and ClassWizard generated code
BEGIN_MESSAGE_MAP(CMainFrame, CMDIFrameWnd)
      //{{AFX_MSG_MAP(CMainFrame)
        // NOTE - the ClassWizard will add and remove mapping macros here.
        // DO NOT EDIT what you see in these blocks of generated code !
      ON_WM_CREATE()
      //}}AFX_MSG_MAP
END_MESSAGE_MAP()
//TICS +*

IMPORTANT NOTES

Do not suppress a rule because there is a false positive in TICS or in case you think the coding standard document should be adjusted. If so, inform the TICS support team instead.
Suppressions are stored in the database. So, although they are not shown in the overviews of a TICS run, they can be made visible in the TICS viewer.

Authentication

The TICS client needs to authenticate itself when communicating with the viewer. Please refer to configuring an authentication token.