Merge Cpplint Pull requests / fix issues

[tkruse]

@itamaro, @mattyclarkson, @massenz, @tychoish, @dirk-thomas, I took the liberty to make branches and pull requests from several outstanding PRs on https://github.com/google/styleguide. I believe that repo is practically dead, and anyway I don't see good reasons why a public linter should be kept in a single same repo as coding guidelines for various languages for Google employees.

I mention you here because you all contributed patches to cpplint. I would like to merge the changes to make a new pypi release of cpplint. The PRs need to be rebased and reviewed, possibly also adding additional tests or consolidating. I'll eagerly merge PRs that have been reviewed by any of you (except by the authors themselves).

If you would like to comment or change your own PRs, or review any of the others, that would make things go faster.

Essential

• Fix extensions #22 Fix issues with alternative file extensions
• Fix wrong report for "public slots" #6 Fix wrong report for "public slots" + Quick hack for QT #8 Quick hack for QT
• Allow end-of-namespace lines that begin with whitespace.  #9 Allow end-of-namespace lines that begin with whitespace.
• Python3000 #12 Python3000 (my master branch already has similar patches)
• cpplint does not detect space before parens google/styleguide#62 cpplint does not detect space before parens
• make pychecker pass
• cpplint gives bogus error on rvalue reference google/styleguide#61 cpplint gives bogus error on rvalue reference
• Explicit variadic constructors #13 Explicit variadic constructors
• Single line lambdas #14 Single line lambdas
• Using namespace literals #16 Using namespace literals
• Add extensible set of header file extensions #11 Added the extensions option to the CPPLINT.cfg option file
• Doxygen #15 Ignore long Doxygen copydoc/copydetails/copybrief lines because doxygen cannot handle linewrap

Nice to have:

• Make "root" flag configurable via CPPLINT.CFG #30 --root in cfg file
• The cpplint returns non-zero when there is at least one message. #7 The cpplint returns non-zero when there is at least one message.
• Make output appear in the Visual Studio Error List #10 Make output appear in the Visual Studio Error List
• Access keyword indent #18 Access keyword indent
• Added custom system headers section #21 Added custom system headers section
• Making cpplint Sonar friendly google/styleguide#14 Sonar-friendly output option
• Add options to change extensions to cli arguments and the CPPLINT.cfg option file #17 Add configuration option for file extensions

[massenz]

@tkruse Thanks for doing that!
I'm currently traveling but will happily follow up on this later this week, or next weekend at the latest.

And, yes, I agree with you: this repo is pretty much "dead".

[mattyclarkson]

@tkruse, good work taking this up. I can rebase our stuff onto yours.

[tkruse]

@mattyclarkson : I merged most of the commits from your fork already, because it was well-tested. Only the py3000 needs merge decisions.

[dirk-thomas]

Any progress on cpplint is good progress 😄

It would be good to consider PEP 8 and PEP 257 at some point (related to google/styleguide#77). Even the code being added and modified is highly inconsistent (e.g. indentation). Maybe changes can at least aim for following the recommendation if the existing code isn't updated immediately.

The conceptionally biggest problem imo is google/styleguide#78. While the proposed changes imply updating existing header guards without the definitions are simply not unique and can collide. Therefore adding support for this with an opt-in option would be good.

[massenz]

@tkruse - do you still need any work from me?
Finally back, now have time to contribute to this, if desired.

There's also this fix (from my fork of styleguide):
https://github.com/massenz/styleguide/commit/9c3afba6458d1b34b05fae88bdb30685dd5e7e1b

To me, the most pressing need would be to make this monster of non-PEP8-horribly-written single-file abomination into a more modular and more manageable set of modules.

[massenz]

But, I'm also wondering whether this is worth the effort, considering clang-format 3.8 addresses many of the reasons why we looked into using cpplint instead.

Do folks have opinions, either way?

[tkruse]

@massenz , you could help by providing unit test for any of the prs. I am traveling right now, I hope to release a new version of cooling when I am back. I don't know what can go into that release, I will add least try to get all issue I marked as 'essential' in. You can look into any of those to help.
Also I consider writing regression test which get frozen versions of real life libraries, and make sure future versions of cooking report the same issues.

I currently do not consider large scale refactoring of cpplint. The Google fork still remains relevant, and I expect more people will contribute to that than to my fork. So the codebases should not diverge too much.

[tkruse]

@gueraf, if you have time, you may join the effort, several PRs still require reviews

[tkruse]

Hi everybody, this is a little mebarassing. A while ago I handed over maintenance duty to @theandrewdavis (and then forgot about it), so these PRs should all be made to https://github.com/theandrewdavis
Never worry, the work is not wasted, and I can easily recreate PRs against that repo from the work made here so far.

[tkruse]

Small update, it seems cpplint is not quite dead at google, they just do the development in their private svn and ignore github PRs:
google/styleguide#130

[massenz]

One day late and one penny short :D
The Mesos community (my original motivation to try and fix cpplint) has
moved on to clang-format, which is what I'd also recommend.

I'm afraid I will no longer be contributing to this, just too much stuff
going on.

Thanks.

On Wednesday, May 18, 2016, Thibault Kruse [email protected] wrote:

Small update, it seems cpplint is not quite dead at google, they just do
the development in their private svn and ignore github PRs:
google/styleguide#130 google/styleguide#130

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#19 (comment)

Sent from my iPhone, please forgive typoz n brvty