BIND 10 #1993: simple style checker
BIND 10 Development
do-not-reply at isc.org
Thu May 24 19:01:02 UTC 2012
#1993: simple style checker
-------------------------------------+-------------------------------------
Reporter: | Owner:
jinmei | Status: new
Type: task | Milestone: Next-Sprint-
Priority: | Proposed
medium | Resolution:
Component: | Sensitive: 0
Unclassified | Sub-Project: Core
Keywords: | Estimated Difficulty: 0
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Description changed by jinmei:
Old description:
> I've noticed we often find some coding style/guidline issues in
> code review. Spending too much time for this level of thing is not
> really productive (the overhead of each specific case may be marginal,
> but if it repeats the total cost could be substantial) and as we have
> more new developers, it'll be more likely/more often to happen.
>
> So I propose some simple checker tool that warns about possible issues
> that are against the documented guideline. The developer is expected
> to run it on the branch diff before asking review. The script doesn't
> have to eliminate false positives completely, as it's only expected to
> be run by human. And it doesn't have to be comprehensive; it should
> be sufficient to catch some common issues:
> - line length
> - (if possible) naming convention (camel or '_'concatinated etc)
> - brace position
> - redundant space at EOL or in blank lines
> - spacing
>
> It would be something similar to google cpplint
> http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
> but can be much simpler and more ad hoc.
New description:
I've noticed we often find some coding style/guidline issues in
code review. Spending too much time for this level of thing is not
really productive (the overhead of each specific case may be marginal,
but if it repeats the total cost could be substantial) and as we have
more new developers, it'll be more likely/more often to happen.
So I propose some simple checker tool that warns about possible issues
that are against the documented guideline. The developer is expected
to run it on the branch diff before asking review. The script doesn't
have to eliminate false positives completely, as it's only expected to
be run by human. And it doesn't have to be comprehensive; it should
be sufficient to catch some common issues:
- line length
- (if possible) naming convention (camel or '_'concatinated etc)
- brace position
- redundant space at EOL or in blank lines
- parenthesis policy (in particular, use them for return)
- spacing
It would be something similar to google cpplint
http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
but can be much simpler and more ad hoc.
--
--
Ticket URL: <http://bind10.isc.org/ticket/1993#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list