metrixpp/swi_config_sample.xml

<?xml version="1.0" encoding="utf-8"?>

<!--
   
    Software Index, Copyright 2010, Software Index Project Team
    Link: http://swi.sourceforge.net
    
    This file is part of Software Index Tool.
    
    Software Index is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, version 3 of the License.
    
    Software Index is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.
    
    You should have received a copy of the GNU General Public License
    along with Software Index.  If not, see <http://www.gnu.org/licenses/>.
    
-->

<!--
    Configuration file is formed in XML format.
    
    Use this file as a 'configration file description' and
    create new configs using this file as a baseline.
    
    Comments below provides with the description for all options.
    Commented XML sections make patterns for your specific extensions.
    Some of them demostrates usage examples.
-->

<!-- Root node 'swi:configuration' is mandatory. It's name is hardcoded. -->
<swi:configuration>

  <!-- Section 'swi:info' is used for descriptive purposes. -->
  <swi:info>
    <!--
        Option 'swi:version' should be equal to 1.
        It is reserved for further extensions.
    -->
    <swi:version>1</swi:version>
    <!--
        Option 'swi:project/swi:name' is used in the final report.
        All objects are references in the following format:
        YOUR_PROJECT_NAME/YOUR_MODULE_NAME/FILE/FUNCTION_NAME
        Changes in this sections automatically reflected in the report.
    -->
    <swi:project>
      <!-- Modify this option in order to refer to the actual name of your solution -->
      <swi:name>YOUR_PROJECT_NAME</swi:name>
    </swi:project>
    <!--
        This section for tracing purposes.
        If you workflow assumes history records in project files,
        this is the place to keep your records
        
        The section can be missed.
    -->
    <swi:history>
      <!-- Section 'swi:revision' can be repeated several times -->
      <swi:revision>
        <swi:name>ALFA</swi:name>
        <swi:user>USER</swi:user>
        <swi:comment>Sample configuration with the description created</swi:comment>
      </swi:revision>
      <!--
          Add here the next 'swi:revision' section, for example:
          <swi:revision>
            <swi:name>BETA</swi:name>
            <swi:user>USER</swi:user>
            <swi:comment>Description of the next update</swi:comment>
          </swi:revision>
      -->
    </swi:history>
  </swi:info>
  
  <!--
      The 'swi:general' section configures global settings for the tool.
      
      The section can be missed.
  -->
  <swi:general>
    <!--
        Filtering of the debug information
        
        The section can be missed.
    -->
    <swi:debug>
     <!--
         The 'swi:enabled' option activates/deativates the tracing:
         Possible values are 'on' and 'off'
         
         By default, the debug is not enabled.
      -->
      <swi:enabled>off</swi:enabled>
    </swi:debug>
  </swi:general>
  
  <!-- Section 'swi:modules' define where to get sources and how to process them. -->
  <swi:modules>
    <!-- Section 'swi:module' can be repeated several times -->
    <swi:module>
      <!--
          Option 'swi:name' is used in the final report.
          All objects are references in the following format:
          YOUR_PROJECT_NAME/YOUR_MODULE_NAME/FILE/FUNCTION_NAME
          Changes in this sections automatically reflected in the report.
         
          Modify this option in order to refer to the actual name of your module
      -->
      <swi:name>YOUR_MODULE_NAME</swi:name>
      <!--
          This is a full path to the directory where module's source files are stored
          It can be relative or full path (recommended).
          If it is relative path, you need to run Software Index tool from the relatively correct folder.
      -->
      <swi:location>/path/to/my/module</swi:location>
      <!--
          Section 'swi:files' which files to process and which to miss.
          
          The section can be missed.
      -->
      <swi:files>
        <!--
            This option is a regular expression.
            If file name (in module's location) is mathced by this expression,
            it is included to the list for processing.
            Otherwise, it is missed and not touched by Software Index tool.
            The example below matches files with the following extensions:
            .c, .h, .cpp, .hpp
            
            By default, all files are included.
        -->
        <swi:include>^.*[.][chCH]([pP][pP])?$</swi:include>
        <!--
            This option is a regular expression.
            If file name (in module's location) is mathced by this expression,
            it is excluded from the list for processing
            (even if it was previously mathced by the previous option).
            The example below matches files with the following extensions:
            .gz.c, .gz.h, .gz.cpp, .gz.hpp
            
            By default, no files are excluded.
        -->
        <swi:exclude>^.*[.][gG][zZ][.][chCH]([pP][pP])?$</swi:exclude>
      </swi:files>
      
      <!--
          The Software Index does not parse 'preprocessor' statements, like a C/C++ compiler.
          It just removes lines with preprocessor defines, includes, conditions and so on.
          As a result a code may include unfolded preprocessor strings
          which are normally replaced/removed by a compiler.
          
          For example, the initial code
              line  1: #define MAXIMUM_NUMBER (100)
              line  2: #ifdef DEBUG
              line  3:     if (currentNumber < MAXIMUM_NUMBER) {
              line  4:         printf("New overflow detected: %d\n", currentNumber);
              line  5:         count++;
              line  6:     }
              line  7: #else
              line  8:     if (currentNumber < MAXIMUM_NUMBER) {
              line  9:         count++;
              line 10:     }
              line 11: #endif
          is converted to:
              line  1: 
              line  2: 
              line  3:     if (currentNumber < MAXIMUM_NUMBER) {
              line  4:         printf("New overflow detected: %d\n", currentNumber);
              line  5:         count++;
              line  6:     }
              line  7: 
              line  8:     if (currentNumber < MAXIMUM_NUMBER) {
              line  9:         count++;
              line 10:     }
              line 11: 
          In the last example, the final code is parsable.
          If all your preprocessor statements are in the similar style and does not
          corrupt the structure of block start/end delimeters as in the example above,
          you do not need to bother about preprocessor stuff.
          
          However, if the initial code includes lines like these:
              line  1: #define MAXIMUM_NUMBER (100)
              line  2:     if (currentNumber < MAXIMUM_NUMBER) {
              line  3: #ifdef DEBUG
              line  4:         printf("New overflow detected: %d\n", currentNumber);
              line  5:         count++;
              line  6:     }
              line  7: #else
              line  8:         count++;
              line  9:     }
              line 10: #endif
          it is not parsable, because brackets mismatch is detected after preprocessing
          (see lines 6 and 9 below):
              line  1: 
              line  2:     if (currentNumber < MAXIMUM_NUMBER) {
              line  3: 
              line  4:         printf("New overflow detected: %d\n", currentNumber);
              line  5:         count++;
              line  6:     }
              line  7: 
              line  8:         count++;
              line  9:     }
              line 10: 
          Thus, in order to use Software Index tool it is necessary to refactor places,
          like in the example above.
          
          The section 'swi:preprocessor' is useful in other cases.
          For example, if the initial code includes the following lines:
              line  1: #define DECLARE_HANDLER(handlerName)                  \
              line  2:     int handlerName(unsigned int stateId,             \
              line  3:                     unsigned int eventId,             \
              line  4:                     struct EVENT_DATA_TYPE eventData)
              line  5: 
              line  6: DECLARE_HANDLER(leftButtonClick);
              line  7: DECLARE_HANDLER(rightButtonClick);
              line  8: 
              line  9: DECLARE_HANDLER(leftButtonClick)
              line 10: {
              line 11:     /* This function is called when left mouse button is clicked */
              line 12:     ...
              line 13: }
              line 14: 
              line 15: DECLARE_HANDLER(rightButtonClick)
              line 16: {
              line 17:     /* This function is called when right mouse button is clicked */
              line 18:     ...
              line 19: }
              line 20: 
          Software Index tool detects function DECLARE_HANDLER twice. As a result, they will be named:
              'DECLARE_HANDLER' and 'DECLARE_HANDLER (2)' accordingly.
          
          The better solution is to preprocess these strings using the preprocessor feature.
          For this particular example, it is recommended to define the rule which replaces the string:
              lines  6,7,9,15: DECLARE_HANDLER(_xxx_)
          by
              lines  6,7,9,15: int _xxx_(unsigned int stateId, unsigned int eventId, struct EVENT_DATA_TYPE eventData)
          where
              _xxx_ is the actual function name.
          In other words, the 'swi:preprocessor' section should include the following XML tags:
              <swi:rule>
                <swi:filepattern>your_regexp_file_pattern</swi:filepattern>
                <swi:searchpattern>([^_a-zA-Z0-9])DECLARE_HANDLER\(([^_a-zA-Z0-9])\)</swi:searchpattern>
                <swi:replacepattern>${1}int ${2}(unsigned int stateId, unsigned int eventId, struct EVENT_DATA_TYPE eventData)</swi:replacepattern>
              </swi:rule>
          As a result, the functions will be detected with the correct names:
              'leftButtonClick' and 'rightButtonClick' accordingly.
          
          'swi:preprocessor' section can be missed.
      -->
      <swi:preprocessor>
        <!-- Section 'swi:rule' can be missed or repeated several times -->
        <swi:rule>
          <!--
              This option is a regular expression.
              If name of file which is under processing is mathced by this expression,
              it is preprocessed according to the rule definitions.
              Otherwise, it is missed and not touched by the internal preprocessor tool.
              The example below matches files with the following extensions:
              .h, .hpp
          -->
          <swi:filepattern>^.*[.][hH]([pP][pP])?$</swi:filepattern>
          <!--
              Options 'swi:searchpattern' and 'swi:replacepattern' are regular expressions.
              Preprocessor searches the code by the 'swi:searchpattern' pattern.
              If it is found it is replaced by 'swi:replacepattern' string,
              which is interpolated before: variables ${1}, ${2}, ... are replaced by actual strings
              from 'swi:searchpattern' regexp hooks.
          -->
          <swi:searchpattern>([^_a-zA-Z0-9])DECLARE_HANDLER\(([^_a-zA-Z0-9])\)</swi:searchpattern>
          <swi:replacepattern>${1}int ${2}(unsigned int stateId, unsigned int eventId, struct EVENT_DATA_TYPE eventData)</swi:replacepattern>
        </swi:rule>
        <!--
            Add here the next 'swi:rule' section, for example:
            <swi:rule>
              <swi:filepattern>.*</swi:filepattern>
              <swi:searchpattern>(\s+)(union\s*)({)</swi:searchpattern>
              <swi:replacepattern>$1$2 _noname_ $3</swi:replacepattern>
            </swi:rule>
        -->
      </swi:preprocessor>
      
      <!--
          Scaner tool is used for global searching and violation reporting.
          If the scaner finds something, it reports the message which is also configured
          and increases the exit code from the Software Index Tool.
          
          For example, if you codding style requires to open the block begging from the new line:
              line  1: 
              line  2:     if (currentNumber < MAXIMUM_NUMBER)
              line  3:     {
              line  4:         count++;
              line  5:     }
              line  6: 
          it is possible to check it by scaner defining the 'swi:searchpattern' in the following way:
              [\n][^{][{]
          This regular expression matches the code which is 'badly' formated:
              line  1: 
              line  2:     if (currentNumber < MAXIMUM_NUMBER) {
              line  3:         count++;
              line  4:     }
              line  5: 
          
          More examples. If you codding style does not allow to have noname structures, enums or unions:
              line  1: 
              line  2:     typedef struct _NAME_HERE_IS_MANDATORY_
              line  3:     {
              line  4:         int a;
              line  5:     } my_type;
              line  6: 
          it is possible to check it by scaner defining the 'swi:searchpattern' in the following way:
              (\s+)((union)|(enum)|(struct))(\s*{)
          This regular expression matches the code which is 'wrongly' written:
              line  1: 
              line  2:     typedef struct // noname here
              line  3:     {
              line  4:         int a;
              line  5:     } my_type;
              line  6: 
          And if the 'swi:messagepattern' equals to:
              Noname '$2' detected.
          the error report looks like this:
              file.c:2: warning: Noname 'struct' detected.
              
          'swi:scaner' section can be missed.
      -->
      <swi:scanner>
        <!-- Section 'swi:rule' can be missed or repeated several times -->
        <swi:rule>
          <!--
              This option is a regular expression.
              If name of file which is under processing is mathced by this expression,
              it is scaned according to the rule definitions.
              Otherwise, it is missed and not touched by the internal scaner tool.
              The example below matches all files.
          -->
          <swi:filepattern>.*</swi:filepattern>
          <!--
              Options 'swi:searchpattern' and 'swi:messagepattern' are regular expressions.
              Scaner searches the code by the 'swi:searchpattern' pattern.
              If it is found the 'swi:messagepattern' string is printed to STDERR,
              'swi:messagepattern' string is interpolated: variables ${1}, ${2}, ... are replaced by actual strings
              from 'swi:searchpattern' regexp hooks.
          -->
          <swi:searchpattern>(\s+)((union)|(enum)|(struct))(\s*{)</swi:searchpattern>
          <swi:messagepattern>Noname '$2' detected.</swi:messagepattern>
            <!--
                The 'swi:codecontent' option defines the content for scanner, it can be:
              
                  initial         - the initial source content
                  code            - the initial code (without comments)
                  comments        - comments only (no code)
                  nopreprocessor  - preprocessor strings excluded (without comments and preprocessor)
                  nostrings       - strings excluded (without comments and strings)
                  purified        - strings and preprocessor excluded (without comments, strings and preprocessor)
                  commentheader   - comments before function's header
                  functionname    - name of a function
                  functionhead    - purified function's header, no body
                  functionbody    - purified function's body, no header
              
                By default, the 'purified' code is scanned
            -->
          <swi:codecontent>purified</swi:codecontent>
        </swi:rule>
        <!--
            Add here the next 'swi:rule' section, for example:
            <swi:rule>
              <swi:filepattern>.*</swi:filepattern>
              <swi:searchpattern>#define\s*([_a-zA-Z0-9]+)\s*[\(]?([0-9]+)[\)]?</swi:searchpattern>
              <swi:messagepattern>Define '${1}' of the number '${2}'
                   should be replaced by 'static const int ${1} = ${2};'</swi:messagepattern>
              <swi:codecontent>nostrings</swi:codecontent>
            </swi:rule>
        -->
        <!--
            If some finding is acceptable and should not be considered as a violation
            it is possible to define the exception and suppress the notification
            in the 'swi:suppress' section below.
        -->
        <swi:suppress>
          <!--
              The exception should be defined in combination with 'swi:message' option.
              If a scanner's message is matched by the regular expression 'swi:message'
              and the object is matched by the regular expression in 'swi:pattern' tag,
              the finding is ignored and not printed to the log and stderr streams.
              
              For example, the following pattern blocks the notification:
                  'Noname 'enum' detected.'
              for the object:
                  YOUR_PROJECT_NAME/YOUR_MODULE_NAME/your_file.c/yourFunction
          -->
          <swi:pattern swi:message="Noname 'enum' detected.">^YOUR_PROJECT_NAME/YOUR_MODULE_NAME/your_file.c/yourFunction$</swi:pattern>
          <!--
              Add here the next 'swi:pattern' section, for example:
              <swi:pattern swi:message="Noname 'struct' detected.">^.*/.*/file2.c/function2$</swi:pattern>
          -->
        </swi:suppress>
        
      </swi:scanner>
      
      <!--
          Indexer measures common software statistics per functions, files, modules and project.
          They are:
          
              STATICTIC-GROUP / STATISTIC-NAME     - DESCRIPTION
              =============== / ================== - ============================
              swi:length      / swi:source         - total number of symbols
              swi:length      / swi:blank          - number of space symbols
              swi:length      / swi:executable     - number of executable symbols
              swi:length      / swi:comment        - number of symbols inside comments
              swi:length      / swi:function:name  - number of symbols in name of a function
              swi:lines       / swi:comment:header - number of lines in a comment before a function/file
              swi:lines       / swi:source         - total number of lines
              swi:lines       / swi:blank          - number of empty lines
              swi:lines       / swi:executable     - number of executable lines
              swi:lines       / swi:comment        - number of lines with comments
              swi:complexity  / swi:blocks         - number of blocks
              swi:complexity  / swi:cyclomatic     - McCabe's (Mayer's) Cyclomatic complexity metric
              swi:complexity  / swi:maxdepth       - Maximum indent level
              swi:count       / swi:functions      - Number of functions
              swi:count       / swi:files          - Number of files
              swi:count       / swi:modules        - Number of modules
              swi:checksum    / swi:source         - Checksum for the source code (compare purposes)
              
          Every statistic is reported incombination with the following types:
          
              STATICTIC-TYPE  - DESCRIPTION
              =============== - ============================
              swi:exact       - exact value
              swi:average     - average value within a distribution
              swi:min         - minimum value within a distribution
              swi:max         - maximum value within a distribution
              swi:total       - sum of values within a distribution
              
          Cumulative types (swi:average, swi:min, swi:max and swi:total) are reported if they are applicable.
          
          'swi:indexer:common' section can be missed.
      -->
      <swi:indexer:common>
        <!-- No settings currently available -->
      </swi:indexer:common>
      
      <!--
          Duplication indexer searches for identical code fragments, calculates total number of symbols
          in continues duplicated fragments per function, file, module and project.
          
          Note: blank symbols (spaces, tabulations, newlines) are ignored when strings are compared.
          
          The duplciation statistic is reported by reference 'swi:duplication/swi:symbols':
          
              STATICTIC-GROUP / STATISTIC-NAME     - DESCRIPTION
              =============== / ================== - ============================
              swi:duplication / swi:symbols        - Number of duplicated symbols
              
          The statistic is reported incombination with the following types:
          
              STATICTIC-TYPE  - DESCRIPTION
              =============== - ============================
              swi:exact       - exact value
              swi:average     - average value within a distribution
              swi:min         - minimum value within a distribution
              swi:max         - maximum value within a distribution
              swi:total       - sum of values within a distribution
              
          Cumulative types (swi:average, swi:min, swi:max and swi:total) are reported if they are applicable.
          
          This internal tool also collects pointers to duplicated fragments and prints them.
          Also, they can be easily extracted from the final report for other needs.
          
          'swi:indexer:dup' section can be missed.
      -->
      <swi:indexer:dup>
        <!--
            The 'swi:codecontent' option defines the content for the duplicatiion searcher, it can be:
            
                initial         - the initial source content
                code            - the initial code (without comments)
                comments        - comments only (no code)
                nopreprocessor  - preprocessor strings excluded (without comments and preprocessor)
                nostrings       - strings excluded (without comments and strings)
                purified        - strings and preprocessor excluded (without comments, strings and preprocessor)
                commentheader   - comments before function's header
                functionname    - name of a function
                functionhead    - purified function's header, no body
                functionbody    - purified function's body, no header
              
              By default, the 'purified' content is used.
            
            Recomendation: if Software Index tool detects a log of duplicated fragments
            which are within function's header (declarations), usually it is the case when
            where are overloaded functions with a huge list of arguments, it is recommended
            to set 'swi:codecontent' option to 'functionbody' value.
        -->
        <swi:codecontent>purified</swi:codecontent>
        <!--
            The 'swi:enabled' option activates/deativates the calculation of the duplication index:
            
                on  - the search tool is launched and the statistic is calculated
                off - the search tool is not started, the statistic is reported by zeros
            
            By default, the this is not enabled
        -->
        <swi:enabled>on</swi:enabled>
          <!--
            The 'swi:minlength' option defines the minimal length of the duplicated fragment.
            In other words, if the duplicated fragment is found it is at least 'swi:minlength' in length
            Too small value, for example 10, results in excessive growth of the total duplication index
            Too large value may cause the empty search result.
            
            By default, it is equal to 100.
          -->
        <swi:minlength>100</swi:minlength>
        <!--
            The 'swi:proximity' option allows to report two code fragments as duplicated
            even if they are not matched exactly till the end.
            It helps to search 'almost' duplicated code fragments instead of 'exactly' duplicated.
            
            This option is a value from 1 till 100.
            
            For example, if there is found group of duplicated code fragments
            which are 100 symbols in length and 'swi:proximity' is equal to 80,
            this group will be extended by other found code fragments
            which have 80 or more the same symbols.
            
            By default, it is equal to 100.
        -->
        <swi:proximity>100</swi:proximity>
        <!--
            All code fragments are related to some function.
            Except global defines, declarations, class definitions and so on.
            Software Index attaches global code to the 'dummy' function with name '>>>GLOBAL<<<'.
            
            The 'swi:globalcode' configures whether the global code should be included
            to the scope of search for duplication.
            
                on  - global code is scaned for duplication
                off - global code is missed
            
            By default, the this option is 'off'.
        -->
        <swi:globalcode>on</swi:globalcode>
      </swi:indexer:dup>

    </swi:module>
    
    <!--
        Add here the next 'swi:module' section.
    -->

  </swi:modules>
  
  <!--
      The 'swi:report' section defines the location for reports and output settings.
  -->
  <swi:report>
    <!--
        This is a full path to the directory where report files should be stored
        It can be relative or full path (recommended).
        If it is relative path, you need to run Software Index tool from the relatively correct folder.
    -->
    <swi:destination>/path/to/the/destination/folder</swi:destination>
    <!--
        The main report is generated to XML format.
        Other files are created from the XML file by converters.
    -->
    <swi:xml>
      <!-- Name of final XML file in 'swi:destination' directory. -->
      <swi:name>swi_report_sample.xml</swi:name>
      <!--
          Software Index process software modules independantly from their versions.
          
          However, if it is executed with a reference to a report generated by 
          Software Index tool for the baseline versions of your modules
              (baseline version - previous version of the product, the state of product
               before the time when changes and updates and/or additions applied)
          it has additional information and can report the modification status
          for every statistic (increased/decreased) and for every
          function, file and module (added, removed, modified, cloned or unmodified).
          
          Description of modification statuses:
              added      - there was no object in the baseline version
                           and it was added to the current version
              removed    - there was object in the baseline version
                           and it was removed from the current version
              modified   - there was object in the baseline version
                           and it was changed/updated
              cloned     - there was object in the baseline version,
                           it was not changed/updated in the new version,
                           but duplication index (swi:duplication/swi:executable)
                           was decreased or increased
              unmodified - the object was now touched
          
          In addition to the extra info, it helps to filter the output information.
          For example, it is possible to print limit overheads for added and
          modified functions only (missing analogues messages for untouched objects).
          
          As a result, Software Index tool can be deployed to the software development
          process without extra work and remakes in your old sources.
          You can always start to measure/control the characteristics of
          objectes (functions) which are affected by your recent updates only,
          improving the total quality step-by-step (version-by-version).
          See 'Example 1' in the next section for examples.
          
          The 'swi:baseline' option points out to the report for the baseline version.
          It should be stored in 'swi:destination' directory.
          If it is not defined,
          it is considered that all objects (functions, files and so on) were added.
      -->
      <swi:baseline>swi_report_sample.xml</swi:baseline>
    </swi:xml>
    <!--
        Notifications are prinited to file and to stderr stream.
        They highlight exceeded limitations of indexes/statistics
        and other notices, warnings and errors.
    -->
    <swi:notifications>
      <!-- Name of log file in 'swi:destination' directory. -->
      <swi:name>swi_report_sample.log</swi:name>
      <!--
          Flags in XML sub-tags in 'swi:error' section
          activate/deactivate counter of errors/notifications.
          If the object with the corresponding modification status
          has some notification (exceeded limit, for example),
          the error counter is increased.
          The final value of the error counter is returned
          to the operation system as exit code.
          Thus, if there are no notifications/errors, exit code is zero.
          
          Options should be equal to some value from the list below:
                on  - counter is increased (selected by default for all)
                off - counter is not increased
          
          Example 1: 'easy deployment of the tool'
              added      - 'on'
              removed    - 'on' or 'off'
              modified   - 'on'
              cloned     - 'on' or 'off'
              unmodified - 'off'
              
          Example 2: 'global control'
              added      - 'on'
              removed    - 'on'
              modified   - 'on'
              cloned     - 'on'
              unmodified - 'on'

          Example 3: 'always success (zero exit code)'
              added      - 'off'
              removed    - 'off'
              modified   - 'off'
              cloned     - 'off'
              unmodified - 'off'
              
          'swi:error' section can be missed.
      -->
      <swi:error>
        <swi:added>on</swi:added>
        <swi:removed>on</swi:removed>
        <swi:modified>on</swi:modified>
        <swi:cloned>on</swi:cloned>
        <swi:unmodified>on</swi:unmodified>
      </swi:error>
      <!--
          The 'swi:print' section defines which messages should be printed
          to the log and to stderr stream. By analogy with the previous 
          configuration section, the flags are defined per modification status.
          There are three types of messages which are configred by 
          'swi:failures', 'swi:modifications' and 'swi:duplications' options.
          
          (*) 'swi:failures'      - notifications about broken limits
              'swi:modifications' - notes about added/modified/cloned/removed objects
              'swi:duplications'  - pointers to the duplicated regions in files
          (*) 'swi:scanmessages'  - messages collected by the internal scaner tool
                                    (see 'swi:scaner' section above)
          
          (*) marks types of messages which affect the exit code (see 'swi:error' section above).
          
          'swi:print' section can be missed. In this case all messages are activated by default.
      -->
      <swi:print>
        <swi:added>
          <swi:failures>on</swi:failures>
          <swi:modifications>off</swi:modifications>
          <swi:duplications>on</swi:duplications>
          <swi:scanmessages>on</swi:scanmessages>
        </swi:added>
        <swi:removed>
          <swi:failures>on</swi:failures>
          <swi:modifications>off</swi:modifications>
          <swi:duplications>on</swi:duplications>
          <swi:scanmessages>on</swi:scanmessages>
        </swi:removed>
        <swi:modified>
          <swi:failures>on</swi:failures>
          <swi:modifications>off</swi:modifications>
          <swi:duplications>on</swi:duplications>
          <swi:scanmessages>on</swi:scanmessages>
        </swi:modified>
        <swi:cloned>
          <swi:failures>on</swi:failures>
          <swi:modifications>off</swi:modifications>
          <swi:duplications>on</swi:duplications>
          <swi:scanmessages>on</swi:scanmessages>
        </swi:cloned>
        <swi:unmodified>
          <swi:failures>on</swi:failures>
          <swi:modifications>off</swi:modifications>
          <swi:duplications>on</swi:duplications>
          <swi:scanmessages>on</swi:scanmessages>
        </swi:unmodified>
      </swi:print>
    </swi:notifications>
  </swi:report>
  
  <!--
      Software Index tool is able to validate
      that the particular statistic is in the acceptable range.
      
      Limits should be defined per:
      STATISTIC-GROUP / STATISTIC-NAME / STATISTIC-TYPE
      (See sections 'swi:indexer:common' and 'swi:indexer:dup' above)
      
      'swi:limits' section can be missed.
  -->
  <swi:limits>
    <!-- 
        For example, if it is required to have proper (not too short)
        comment header, it is necessary to limit the statistic:
            'swi:lines/swi:comment:header/swi:exact'
        It is demonstarted in the following section:
    -->
    <!-- STATISTIC-GROUP -->
    <swi:lines>
      <!-- STATISTIC-NAME -->
      <swi:comment:header>
        <!-- STATISTIC-TYPE -->
        <swi:exact>
          <!--
              After that, actual limits should be defined for three levels:
                  info, notice, warning
                  
              The common rule is that options should be in order:
                  'swi:info' < 'swi:notice' < 'swi:warning'
                OR:
                  'swi:info' > 'swi:notice' > 'swi:warning'
                  
              Note: limits can be negative, in this case they do not have any sense.
              
              In the example below, no messages are printed for a function
              if comment header before includes 5 lines at least.
              If it is so, the 'regular' level is attached to this function.
              If comment has 3-4 lines, level 'info' is assigned.
              If comment has 1-2 lines, level 'notice' is assigned.
              If ther� is no comments at all (0 lines), level 'warning' is assigned.
          -->
          <swi:info>5</swi:info>
          <swi:notice>3</swi:notice>
          <swi:warning>1</swi:warning>
          
          <!--
              If some object is evaluated in non-regular level (info/notice/warning)
              and you consider that it is too excessive to fix it
              (or just there are no needs/benefits to do it),
              it is possible to define the exception and suppress the notification
              in the 'swi:suppress' section below.
              
              The exception should be defined in combination with 'swi:level' option.
              If there is notification for the object:
                  MY_PROJECT/MY_MODULE/my_file.c/myFunction
              with 'notice' level, the 'swi:level' should be equal to 'notice'.
              Otherwise, the notification will be still printed.
              In other words, severity of the message and suppress level should be equal.
              
              Also, one rule can suppress several objects. An object is considered as
              suppressed if it is matched by regular expression in 'swi:pattern' option.
              
              For example, the regexp pattern
                  MY_PROJECT/MY_MODULE/my_file.c/.*
              suppresses all functions in my_file.c in scope of
              MY_MODULE module in MY_PROJECT project.
              
              However, it it NOT recommended to use multiple suppressing,
              due to possible missmatch in severity of messages:
              For example, if there are two functions:
                  MY_PROJECT/MY_MODULE/my_file.c/myFunction1
                  MY_PROJECT/MY_MODULE/my_file.c/myFunction2
              and one of them is reported by the message with 'notice' level
              but the second is evaluated in 'regular' level,
              the 'swi:pattern' rule:
                  MY_PROJECT/MY_MODULE/my_file.c/.*
              will always result in the unsuppressable message,
              either for the first or for the second function.
              
              It is better to suppress all objects by their full reference.
              For example (see the previous example for prehistory)
                  <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE/my_file.c/myFunction1$</swi:pattern>
              Symbols '^' and '$' are special regexp modifiers. They require immidiate borders in the name.
          -->
          <swi:suppress>
            <!-- Section 'swi:pattern' can be repeated several times -->
            <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE/my_file.c/myFunction1$</swi:pattern>
            <!--
                Add here the next 'swi:pattern' section, for example:
                <swi:pattern swi:level="warning">^.*/.*/file2.c/operator new[]$</swi:pattern>
            -->
          </swi:suppress>
      
        </swi:exact>
      </swi:comment:header>

      <!-- STATISTIC-NAME -->
      <swi:comment>
        <!--
            This is the next example of a limit for statistic.
            It demonstrates how to limit the relative values.
            For example, it is required to have at least 30% of comments per every function.
            This is defined by the relation:
            
            'swi:lines/swi:comment/swi:exact' / 'swi:lines/swi:executable/swi:exact' * 100%.
            
            In this case it is necessary to limit 'swi:lines/swi:comment/swi:exact'
            (what we do here) in the relation with 'swi:lines/swi:executable/swi:exact'.
        -->
        <swi:exact swi:relation="swi:lines/swi:executable/swi:exact">
          <!-- 0.3  is 30% -->
          <swi:info>0.3</swi:info>
          <!-- 0.25 is 25% -->
          <swi:notice>0.25</swi:notice>
          <!-- 0.2  is 20% -->
          <swi:warning>0.2</swi:warning>
          
          <!--
              Add here suppress section, if it is needed. For example:
              <swi:suppress>
                <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE/my_file.c/myFunction1$</swi:pattern>
                <swi:pattern swi:level="info">^MY_PROJECT/MY_MODULE/my_file.c/myFunction2$</swi:pattern>
              </swi:suppress>
          -->
        </swi:exact>
      </swi:comment>
      
      <!-- STATISTIC-NAME -->
      <swi:executable>
        <!--
            The previous examples require to limit the low bound of exact value.
            This sample demonstrates the limitation for total upper value.
            
            For example, sometimes it is useful to require to have short files,
            because they are easily maintainable in most cases.
            The settings in this sections allows to do it:
            no messages are printed for a file
            if total number of executable lines less than or equal to 1000.
        -->
        <swi:total>
          <swi:info>1000</swi:info>
          <swi:notice>1500</swi:notice>
          <swi:warning>2000</swi:warning>
          
          <!--
              Most likely that you will need to suppress messages for modules,
              because total value of lines in a module is a sum of lines in all files.
          -->
          <swi:suppress>
            <!-- Section 'swi:pattern' can be repeated several times -->
            <swi:pattern swi:level="warning">^MY_PROJECT/MY_MODULE$</swi:pattern>
            <!--
                Add here the next 'swi:pattern' section, for example:
                <swi:pattern swi:level="warning">^MY_PROJECT/MY_MODULE$</swi:pattern>
            -->
          </swi:suppress>
        </swi:total>
      </swi:executable>
      
      <!-- STATISTIC-NAME -->
      <swi:source>
        <!--
            This example is an extension for the previous.
            Here the limitation is applied for total values of files, modules and project
            at the same time.
            
            The settings in this sections allows to do it:
            a) no messages (info) are printed for a file
               if total number of source lines less than or equal to 1000.
            b) no messages (notices) are printed for a module
               if total number of source lines less than or equal to 10000.
            c) no messages (notices) are printed for a project
               if total number of source lines less than or equal to 100000.
        -->
        <swi:total>
          <!-- Limit for files -->
          <swi:info>1000</swi:info>
          <!-- Limit for modules -->
          <swi:notice>10000</swi:notice>
          <!-- Limit for the project -->
          <swi:warning>100000</swi:warning>
          
          <!--
              Most likely that you will need to suppress info messages for modules and
              notice messages for the project,
              because total value of lines in a module is a sum of lines in all files,
              and total value of lines in project is a sum of lines in all modules.
          -->
          <swi:suppress>
            <!-- Section 'swi:pattern' can be repeated several times -->
            <swi:pattern swi:level="info">^MY_PROJECT/MY_MODULE$</swi:pattern>
            <swi:pattern swi:level="notice">^MY_PROJECT$</swi:pattern>
            <!--
                Add here the next 'swi:pattern' section, for example:
                <swi:pattern swi:level="info">^MY_PROJECT/MY_MODULE$</swi:pattern>
            -->
          </swi:suppress>
        </swi:total>
      </swi:source>

    </swi:lines>

    <!-- STATISTIC-GROUP -->
    <swi:complexity>
      <!-- STATISTIC-NAME -->
      <swi:cyclomatic>
        <!-- STATISTIC-TYPE -->
        <swi:exact>
          <!--
              In the example below, no messages are printed for a function
              if cyclomatic complexity index less than or equal to 7.
              It indicates about proper (low) level of logical
              branching in a subroutine. Low level of this index
              more or less grants decreased costs for mainteinability
              and further development, minimal probability of bad fixes,
              better and easier understanding of a logical part of SW.
          -->
          <swi:info>7</swi:info>
          <swi:notice>10</swi:notice>
          <swi:warning>15</swi:warning>
          <!--
              Add here suppress section, if it is needed. For example:
              <swi:suppress>
                <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE/my_file.c/myFunction1$</swi:pattern>
                <swi:pattern swi:level="info">^MY_PROJECT/MY_MODULE/my_file.c/myFunction2$</swi:pattern>
              </swi:suppress>
          -->
        </swi:exact>
      </swi:cyclomatic>
    </swi:complexity>
    
    <!--
        The following section defines the limitation for duplication index.
        In the example, it is required to control exact relative
        duplication index for functions and total relative
        duplication index for files, modules and project.
    -->
    <!-- STATISTIC-GROUP -->
    <swi:duplication>
      <!-- STATISTIC-NAME -->
      <swi:symbols>
        <!-- STATISTIC-TYPE -->
        <swi:exact swi:relation="swi:length/swi:executable/swi:exact">
          <swi:info>0.30</swi:info>
          <swi:notice>0.40</swi:notice>
          <swi:warning>0.60</swi:warning>
          <!--
              Add here suppress section, if it is needed. For example:
              <swi:suppress>
                <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE/my_file.c/myFunction1$</swi:pattern>
                <swi:pattern swi:level="info">^MY_PROJECT/MY_MODULE/my_file.c/myFunction2$</swi:pattern>
              </swi:suppress>
          -->
        </swi:exact>
        
        <!-- STATISTIC-TYPE -->
        <swi:total swi:relation="swi:length/swi:executable/swi:total">
          <swi:info>0.30</swi:info>
          <swi:notice>0.40</swi:notice>
          <swi:warning>0.60</swi:warning>
          <!--
              Add here suppress section, if it is needed. For example:
              <swi:suppress>
                <swi:pattern swi:level="warning">^MY_PROJECT/MY_MODULE/my_file.c$</swi:pattern>
                <swi:pattern swi:level="notice">^MY_PROJECT/MY_MODULE$</swi:pattern>
                <swi:pattern swi:level="info">^MY_PROJECT$</swi:pattern>
              </swi:suppress>
          -->
        </swi:total>
      </swi:symbols>
    </swi:duplication>
    
    <!--
        Add here more sections with definition of limits if it is needed.
    -->
    
  </swi:limits>

</swi:configuration>