Provided by: cpplint_1.6.1-3_all bug

NAME

       cpplint - Static code checker for C++

DESCRIPTION

       Syntax: cpplint.py [--verbose=#] [--output=emacs|eclipse|vs7|junit|sed|gsed]

              [--filter=-x,+y,...]       [--counting=total|toplevel|detailed]     [--root=subdir]
              [--repository=path]   [--linelength=digits]   [--headers=x,y,...]     [--recursive]
              [--exclude=path]                                         [--extensions=hpp,cpp,...]
              [--includeorder=default|standardcfirst] [--quiet] [--version]

              <file> [file] ...

              Style checker for C/C++ source files.  This is a fork of the Google  style  checker
              with minor extensions.

              The style guidelines this tries to follow are those in

              https://google.github.io/styleguide/cppguide.html

              Every  problem  is given a confidence score from 1-5, with 5 meaning we are certain
              of the problem, and 1 meaning it could be a legitimate construct.  This  will  miss
              some errors, and is not a substitute for a code review.

              To  suppress  false-positive errors of a certain category, add a 'NOLINT(category)'
              comment to the line.  NOLINT or NOLINT(*) suppresses errors of  all  categories  on
              that line.

              The  files  passed  in will be linted; at least one file must be provided.  Default
              linted extensions are ['c', 'c++', 'cc', 'cpp', 'cu',  'cuh',  'cxx',  'h',  'h++',
              'hh', 'hpp', 'hxx'].  Other file types will be ignored.  Change the extensions with
              the --extensions flag.

              Flags:

              output=emacs|eclipse|vs7|junit|sed|gsed

       By default, the output is formatted to ease emacs parsing.
              Visual Studio

       compatible output (vs7) may also be used.
              Further support exists for

              eclipse (eclipse), and JUnit (junit). XML parsers such as those used in Jenkins and
              Bamboo  may also be used.  The sed format outputs sed commands that should fix some
              of the errors.  Note that this requires gnu sed. If that is installed  as  gsed  on
              your  system  (common  e.g.  on  macOS  with  homebrew) you can use the gsed output
              format. Sed commands are written to stdout, not stderr, so you should  be  able  to
              pipe output straight to a shell to run the fixes.

              verbose=#

              Specify  a  number 0-5 to restrict errors to certain verbosity levels.  Errors with
              lower verbosity levels have lower confidence  and  are  more  likely  to  be  false
              positives.

              quiet

              Don't print anything if no errors are found.

              filter=-x,+y,...

              Specify  a  comma-separated  list of category-filters to apply: only error messages
              whose category names pass the filters will be printed.  (Category names are printed
              with  the message and look like "[whitespace/indent]".)  Filters are evaluated left
              to right.  "-FOO" means "do not print categories  that  start  with  FOO".   "+FOO"
              means "do print categories that start with FOO".

              Examples: --filter=-whitespace,+whitespace/braces

              --filter=-whitespace,-runtime/printf,+runtime/printf_format
              --filter=-,+build/include_what_you_use

              To see a list of all the categories used in cpplint, pass no arg:

       --filter=

              counting=total|toplevel|detailed

              The total number of errors found is always printed. If 'toplevel' is provided, then
              the  count  of  errors  in  each  of  the  top-level  categories  like  'build' and
              'whitespace' will also be printed. If 'detailed'  is  provided,  then  a  count  is
              provided for each category like 'build/class'.

              repository=path

              The  top  level  directory  of  the repository, used to derive the header guard CPP
              variable. By default, this is determined by searching  for  a  path  that  contains
              .git,  .hg,  or  .svn. When this flag is specified, the given path is used instead.
              This option allows the header guard CPP  variable  to  remain  consistent  even  if
              members of a team have different repository root directories (such as when checking
              out a subdirectory with SVN). In addition, users of non-mainstream version  control
              systems can use this flag to ensure readable header guard CPP variables.

              Examples:

              Assuming that Alice checks out ProjectName and Bob checks out ProjectName/trunk and
              trunk contains src/chrome/ui/browser.h, then with no --repository flag, the  header
              guard CPP variable will be:

              Alice        =>        TRUNK_SRC_CHROME_BROWSER_UI_BROWSER_H_        Bob         =>
              SRC_CHROME_BROWSER_UI_BROWSER_H_

              If Alice  uses  the  --repository=trunk  flag  and  Bob  omits  the  flag  or  uses
              --repository=. then the header guard CPP variable will be:

              Alice => SRC_CHROME_BROWSER_UI_BROWSER_H_ Bob   => SRC_CHROME_BROWSER_UI_BROWSER_H_

              root=subdir

              The  root directory used for deriving header guard CPP variable.  This directory is
              relative to the  top  level  directory  of  the  repository  which  by  default  is
              determined  by  searching  for a directory that contains .git, .hg, or .svn but can
              also be controlled with the --repository flag.  If the specified directory does not
              exist, this flag is ignored.

              Examples:

              Assuming  that  src is the top level directory of the repository (and cwd=top/src),
              the header guard CPP variables for src/chrome/browser/ui/browser.h are:

              No flag  =>  CHROME_BROWSER_UI_BROWSER_H_  --root=chrome  =>  BROWSER_UI_BROWSER_H_
              --root=chrome/browser         =>         UI_BROWSER_H_         --root=..         =>
              SRC_CHROME_BROWSER_UI_BROWSER_H_

              linelength=digits

              This is the  allowed  line  length  for  the  project.  The  default  value  is  80
              characters.

              Examples:

       --linelength=120

              recursive

              Search  for files to lint recursively. Each directory given in the list of files to
              be linted is replaced by all files that descend from  that  directory.  Files  with
              extensions not in the valid extensions list are excluded.

              exclude=path

              Exclude  the  given  path  from  the list of files to be linted. Relative paths are
              evaluated relative to the current directory and shell globbing is  performed.  This
              flag can be provided multiple times to exclude multiple files.

              Examples:

       --exclude=one.cc

       --exclude=src/*.cc

       --exclude=src/*.cc --exclude=test/*.cc

              extensions=extension,extension,...

              The allowed file extensions that cpplint will check

              Examples:

       --extensions=c,c++,cc,cpp,cu,cuh,cxx,h,h++,hh,hpp,hxx

              includeorder=default|standardcfirst

              For  the  build/include_order  rule, the default is to blindly assume angle bracket
              includes with file extension are c-system-headers (default), even knowing this will
              have  false classifications.  The default is established at google.  standardcfirst
              means to instead use an allow-list of known c  headers  and  treat  all  others  as
              separate  group  of "other system headers". The C headers included are those of the
              C-standard lib and closely related ones.

              headers=x,y,...

              The header extensions  that  cpplint  will  treat  as  .h  in  checks.  Values  are
              automatically added to --extensions list.

              (by  default,  only  files  with extensions ['cuh', 'h', 'h++', 'hh', 'hpp', 'hxx']
              will be assumed to be headers)

              Examples:

       --headers=cuh,h,h++,hh,hpp,hxx

       --headers=hpp,hxx

       --headers=hpp

              cpplint.py supports per-directory configurations specified  in  CPPLINT.cfg  files.
              CPPLINT.cfg  file can contain a number of key=value pairs.  Currently the following
              options are supported:

              set  noparent   filter=+filter1,-filter2,...    exclude_files=regex   linelength=80
              root=subdir headers=x,y,...

              "set  noparent"  option  prevents  cpplint  from  traversing directory tree upwards
              looking for more .cfg files in parent directories. This option is usually placed in
              the top-level project directory.

              The  "filter"  option is similar in function to --filter flag. It specifies message
              filters in addition to the |_DEFAULT_FILTERS| and those specified through  --filter
              command-line flag.

              "exclude_files" allows to specify a regular expression to be matched against a file
              name. If the expression matches, the file  is  skipped  and  not  run  through  the
              linter.

              "linelength" allows to specify the allowed line length for the project.

              The  "root"  option  is similar in function to the --root flag (see example above).
              Paths are relative to the directory of the CPPLINT.cfg.

              The "headers" option is similar in function to  the  --headers  flag  (see  example
              above).

              CPPLINT.cfg  has  an effect on files in the same directory and all sub-directories,
              unless overridden by a nested configuration file.

              Example file:

              filter=-build/include_order,+build/include_alpha exclude_files=.*\.cc

              The   above   example   disables   build/include_order    warning    and    enables
              build/include_alpha  as well as excludes all .cc from being processed by linter, in
              the current directory (where the .cfg file is located) and all sub-directories.