Skip to content

README.rst: Do minor cleanup and add self as a maintainer #434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cclauss wants to merge 2 commits into from
Closed

README.rst: Do minor cleanup and add self as a maintainer #434

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dd2490c
README.rst: Do minor cleanup and add self as a maintainer
cclauss Apr 19, 2026
3b8e94d
Update README.rst
cclauss Apr 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 17 additions & 10 deletions README.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,20 +25,26 @@ cpplint - static code checker for C++

Cpplint is a command-line tool to check C/C++ files for style issues according to `Google's C++ style guide <http://google.github.io/styleguide/cppguide.html>`_.

Cpplint used to be developed and maintained by Google Inc. at `google/styleguide <https://github.com/google/styleguide>`_. Nowadays, `Google is no longer maintaining the public version of cpplint <https://github.com/google/styleguide/pull/528#issuecomment-592315430>`_, and pretty much everything in their repo's PRs and issues about cpplint have gone unimplemented.
Cpplint is a friendly fork of Google's original tool at `google/styleguide <https://github.com/google/styleguide>`_. Nowadays, `Google no longer maintains a public version of cpplint <https://github.com/google/styleguide/pull/528#issuecomment-592315430>`_, and many issues and pull requests remain unimplemented.

This fork aims to update cpplint to modern specifications, and be (somewhat) more open to adding fixes and features to make cpplint usable in wider contexts.


Installation
============

Use [`pipx`](https://pipx.pypa.io) to install cpplint from PyPI, run:
Use `pipx <https://pipx.pypa.io>`_ to install cpplint from PyPI, run:

.. code-block:: bash

$ pipx install cpplint

Or use `uv <https://docs.astral.sh/uv>`_ to install cpplint from PyPI, run:
Comment on lines +36 to +42

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Use `pipx <https://pipx.pypa.io>`_ to install cpplint from PyPI, run:
.. code-block:: bash
$ pipx install cpplint
Or use `uv <https://docs.astral.sh/uv>`_ to install cpplint from PyPI, run:
To use `uv <https://docs.astral.sh/uv>`_ to install cpplint from PyPI as a tool, run:

Methinks pipx is a little outmoded

Since it's just a PyPI package name, I think just doing one PyPI-compliant tool is enough unless it can trigger some special hijinks. I don't want this to attract flies that try to add every PyPI tool in existence.

@cclauss cclauss Apr 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pipx comes from the Python Packaging Authority, like pip does, so some people may trust it more.

uv was recently purchased by OpenAI, which some people might not trust in their daily toolchain.

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can trust users to select the tool that they'd like, and it's clear enough that cpplint is the package name on PyPI to feed into the tool that they'd like.

@cclauss cclauss Apr 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you blocking progress over this?

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not; this is the smallest thing among all my comments here. I won't block because of this as long as 1. we go "to use" instead of "use" for grammar 2. the other things above are resolved.

TL;DR: I'm blocking because of the version number–bumping precedent this is setting for the hook, not this.

@cclauss cclauss Apr 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use this or use that proper English.

@aaronliu0130 aaronliu0130 Apr 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

("Use" itself isn't the grammar problem, it's the comma. You've got two independent clauses joined with a comma splice. "To" makes the first one dependent and fix the grammar error.)

Again, though, I think the above thread's far more important.


.. code-block:: bash

$ uv tool install cpplint

Usage
-----
.. code-block:: bash
Expand All @@ -56,7 +62,7 @@ cpplint can also be run as a pre-commit hook by adding to `.pre-commit-config.ya
.. code-block:: yaml

- repo: https://github.com/cpplint/cpplint
rev: 2.0.0
rev: 2.0.2

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the implication that we'll have to update a version number in the README every release. Maybe we could pin this to a version number significant to us, or just make it like this:?

Suggested change
rev: 2.0.2
rev: # cpplint version number

@cclauss cclauss Apr 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. That is not usable out-of-the-box.

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why it has to be. It's very clear how it can be usable out-of-the-box. READMEs are usually quite static.

@cclauss cclauss Apr 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's agree to disagree. Repos occasionally do pre-commit autoupdate but I am OK for them to use an older version until they do so.

Should we add a step in our release process to update the README?

@aaronliu0130 aaronliu0130 Apr 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am OK for them to use an older version until they do so.

Alright, let's

pin this to a version number significant to us

, then. I personally want to pin it at the next release (I'm thinking of making it 2.1.0. We should be able to to do the release process after the currently open PRs are merged, which shouldn't take too long and we can wait for. Even #426 where the PR creator hasn't responded I should be able to fix up quickly) because of how wide the namespace indentation false positives it fixes are.

I do not want to bump it every release, as you suggest, though. That clogs up the README's file history without introducing new information.

hooks:
- id: cpplint
args:
Expand All @@ -65,14 +71,14 @@ cpplint can also be run as a pre-commit hook by adding to `.pre-commit-config.ya
Changes
=======

* python 3 compatibility
* more default file extensions
* customizable file extensions with the --extensions argument
* continuous integration on github
* support for recursive file discovery via the --recursive argument
* support for excluding files via --exclude
* Python 3 compatibility
* JUnit XML output format
* Overriding repository root auto-detection via --repository
* More default file extensions
* Continuous integration on GitHub
* Support for excluding files via ``--exclude``
* Customizable file extensions with the ``--extensions`` argument
* Support for recursive file discovery via the ``--recursive`` argument
* Overriding repository root auto-detection via ``--repository``
Comment thread
aaronliu0130 marked this conversation as resolved.
* Support ``#pragma once`` as an alternative to header include guards
* ... and `quite a bit <https://github.com/cpplint/cpplint/blob/develop/CHANGELOG.rst>`_ more

Expand All @@ -87,6 +93,7 @@ Maintainers
-----------

* `@aaronliu0130 <https://github.com/aaronliu0130>`_
* `@cclauss <https://github.com/cclauss>`_
* `@jayvdb <https://github.com/jayvdb>`_

Former
Expand Down