title	description
cpplint configuration in MegaLinter	How to use cpplint (configure, ignore files, ignore errors, help & version documentations) to analyze CPP files

cpplint

cpplint is a command-line tool that enforces Google's C++ Style Guide, helping teams maintain consistent and readable C++ code. It focuses on style, formatting, and best practice compliance rather than logic errors.

Key Features:

Google C++ Style Guide: Enforces comprehensive style guidelines used by Google's C++ projects
Header File Checking: Validates include guards, header ordering, and proper header usage
Naming Conventions: Ensures consistent naming for variables, functions, classes, and namespaces
Formatting Compliance: Checks indentation, line length, spacing, and comment formatting
Best Practices: Detects deprecated constructs, improper use of C++ features, and potential style issues
Configurable Rules: Allows filtering and customization of specific style checks
Incremental Checking: Can be run on individual files or as part of code quality validation

cpplint documentation

Version in MegaLinter: 2.0.2
Visit Official Web Site{target=_blank}
See Index of problems detected by cpplint{target=_blank}

{target=_blank}

Configuration in MegaLinter

Enable cpplint by adding CPP_CPPLINT in ENABLE_LINTERS variable
Disable cpplint by adding CPP_CPPLINT in DISABLE_LINTERS variable

Variable	Description	Default value
CPP_CPPLINT_ARGUMENTS	User custom arguments to add in linter CLI call Ex: `-s --foo "bar"`
CPP_CPPLINT_COMMAND_REMOVE_ARGUMENTS	User custom arguments to remove from command line before calling the linter Ex: `-s --foo "bar"`
CPP_CPPLINT_FILTER_REGEX_INCLUDE	Custom regex including filter Ex: `(src\|lib)`	Include every file
CPP_CPPLINT_FILTER_REGEX_EXCLUDE	Custom regex excluding filter Ex: `(test\|examples)`	Exclude no file
CPP_CPPLINT_CLI_LINT_MODE	Override default CLI lint mode - `file`: Calls the linter for each file - `list_of_files`: Call the linter with the list of files as argument - `project`: Call the linter from the root of the project	`list_of_files`
CPP_CPPLINT_FILE_EXTENSIONS	Allowed file extensions. `"*"` matches any extension, `""` matches empty extension. Empty list excludes all files Ex: `[".py", ""]`	`[".cpp", ".h", ".cc", ".hpp", ".cxx", ".cu", ".hxx", ".c++", ".hh", ".h++", ".cuh"]`
CPP_CPPLINT_FILE_NAMES_REGEX	File name regex filters. Regular expression list for filtering files by their base names using regex full match. Empty list includes all files Ex: `["Dockerfile(-.+)?", "Jenkinsfile"]`	Include every file
CPP_CPPLINT_PRE_COMMANDS	List of bash commands to run before the linter	None
CPP_CPPLINT_POST_COMMANDS	List of bash commands to run after the linter	None
CPP_CPPLINT_UNSECURED_ENV_VARIABLES	List of env variables explicitly not filtered before calling CPP_CPPLINT and its pre/post commands	None
CPP_CPPLINT_DISABLE_ERRORS	Run linter but consider errors as warnings	`false`
CPP_CPPLINT_DISABLE_ERRORS_IF_LESS_THAN	Maximum number of errors allowed	`0`
CPP_CPPLINT_CLI_EXECUTABLE	Override CLI executable	`['cpplint']`

MegaLinter Flavors

This linter is available in the following flavors

Flavor	Description	Embedded linters
all	Default MegaLinter Flavor	127
c_cpp	Optimized for pure C/C++ projects	56
cupcake	MegaLinter for the most commonly used languages	88
dotnet	Optimized for C, C++, C# or VB based projects	64
dotnetweb	Optimized for C, C++, C# or VB based projects with JS/TS	73
python	Optimized for PYTHON based projects	65

Behind the scenes

How are identified applicable files

File extensions: .cpp, .h, .cc, .hpp, .cxx, .cu, .hxx, .c++, .hh, .h++, .cuh

How the linting is performed

cpplint is called once with the list of files as arguments (list_of_files CLI lint mode)

Example calls

cpplint myfile.cpp

Help content

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]
                   [--config=filename]
                   [--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 certain categories, add a
  'NOLINT(category[, category...])' comment to the line.  NOLINT or NOLINT(*)
  suppresses errors of all categories on that line. To suppress categories
  on the next line use NOLINTNEXTLINE instead of NOLINT. To suppress errors in
  a block of code 'NOLINTBEGIN(category[, category...])' comment to a line at
  the start of the block and to end the block add a comment with 'NOLINTEND'.
  NOLINT blocks are inclusive so any statements on the same line as a BEGIN
  or END will have the error suppression applied.

  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=

      Filters can directly be limited to files and also line numbers. The
      syntax is category:file:line , where line is optional. The filter limitation
      works for both + and - and can be combined with ordinary filters:

      Examples: --filter=-whitespace:foo.h,+whitespace/braces:foo.h
                --filter=-whitespace,-runtime/printf:foo.h:14,+runtime/printf_format:foo.h
                --filter=-,+build/include_what_you_use:foo.h:321

    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 'legal/copyright'.

    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.

    config=filename
      Search for config files with the specified name instead of CPPLINT.cfg

    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.

Installation on mega-linter Docker image

Dockerfile commands :

# renovate: datasource=pypi depName=cpplint
ARG PIP_CPPLINT_VERSION=2.0.2

PIP packages (Python):
- cpplint==2.0.2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!