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.

cpplint 1.6.1                                     December 2023                                       CPPLINT(1)