Revision 1493

trunk/utilities/cpplint.py (revision 1493)
1
# Modified for ADMB style checking.
2
#
3
# Copyright (c) 2009 Google Inc. All rights reserved.
4
#
5
# Redistribution and use in source and binary forms, with or without
6
# modification, are permitted provided that the following conditions are
7
# met:
8
#
9
#    * Redistributions of source code must retain the above copyright
10
# notice, this list of conditions and the following disclaimer.
11
#    * Redistributions in binary form must reproduce the above
12
# copyright notice, this list of conditions and the following disclaimer
13
# in the documentation and/or other materials provided with the
14
# distribution.
15
#    * Neither the name of Google Inc. nor the names of its
16
# contributors may be used to endorse or promote products derived from
17
# this software without specific prior written permission.
18
#
19
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
20
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
21
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
22
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
23
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
24
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
25
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
26
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
27
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
28
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
29
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
30

  
31
# Here are some issues that I've had people identify in my code during reviews,
32
# that I think are possible to flag automatically in a lint tool.  If these were
33
# caught by lint, it would save time both for myself and that of my reviewers.
34
# Most likely, some of these are beyond the scope of the current lint framework,
35
# but I think it is valuable to retain these wish-list items even if they cannot
36
# be immediately implemented.
37
#
38
#  Suggestions
39
#  -----------
40
#  - Check for no 'explicit' for multi-arg ctor
41
#  - Check for boolean assign RHS in parens
42
#  - Check for ctor initializer-list colon position and spacing
43
#  - Check that if there's a ctor, there should be a dtor
44
#  - Check accessors that return non-pointer member variables are
45
#    declared const
46
#  - Check accessors that return non-const pointer member vars are
47
#    *not* declared const
48
#  - Check for using public includes for testing
49
#  - Check for spaces between brackets in one-line inline method
50
#  - Check for no assert()
51
#  - Check for spaces surrounding operators
52
#  - Check for 0 in pointer context (should be NULL)
53
#  - Check for 0 in char context (should be '\0')
54
#  - Check for camel-case method name conventions for methods
55
#    that are not simple inline getters and setters
56
#  - Check that base classes have virtual destructors
57
#    put "  // namespace" after } that closes a namespace, with
58
#    namespace's name after 'namespace' if it is named.
59
#  - Do not indent namespace contents
60
#  - Avoid inlining non-trivial constructors in header files
61
#    include base/basictypes.h if DISALLOW_EVIL_CONSTRUCTORS is used
62
#  - Check for old-school (void) cast for call-sites of functions
63
#    ignored return value
64
#  - Check gUnit usage of anonymous namespace
65
#  - Check for class declaration order (typedefs, consts, enums,
66
#    ctor(s?), dtor, friend declarations, methods, member vars)
67
#
68

  
69
"""Does google-lint on c++ files.
70

  
71
The goal of this script is to identify places in the code that *may*
72
be in non-compliance with google style.  It does not attempt to fix
73
up these problems -- the point is to educate.  It does also not
74
attempt to find all problems, or to ensure that everything it does
75
find is legitimately a problem.
76

  
77
In particular, we can get very confused by /* and // inside strings!
78
We do a small hack, which is to ignore //'s with "'s after them on the
79
same line, but it is far from perfect (in either direction).
80
"""
81

  
82
import codecs
83
import getopt
84
import math  # for log
85
import os
86
import re
87
import sre_compile
88
import string
89
import sys
90
import unicodedata
91

  
92

  
93
_USAGE = """
94
Syntax: cpplint.py [--verbose=#] [--output=vs7] [--filter=-x,+y,...]
95
                   [--counting=total|toplevel|detailed]
96
        <file> [file] ...
... This diff was truncated because it exceeds the maximum size that can be displayed.

Also available in: Unified diff