Re: [Widelands-public] New style checker ready

[Philipp N. <wid...@az...>]

Hi!

On Wed, Apr 29, 2009 at 01:00:25PM +0200, Holger Rapp wrote:
> [New Style checker]
Nice, seems to be quite fast indeed!

1)
I would prefer it if the style checker would only place the
build/*.stylecheck file if the check was silently passed. Current
implementation only checks each file once, even if something was found.

2)
There are cases when the two checker implementations differ in a
conflicting way. If I silence the python checker in
src/trigger/trigger_player_area.cc, the ada version complains about
indentation being to shallow.

Consider: (tab shown as ___, space as  )
[from src/trigger/trigger_player_area.cc, line 48]

Revision 3947 (silent with ada checker):
1______m_player_area = Player_Area<Area<FCoords> >
2_________(s.get_Player_Number("player", map.get_nrplayers(), 1),
3_________ Area<FCoords>
4_________ ___(map.get_fcoords
5_________ ___ ___(s.get_safe_int("version") == 1
6_________ ___ ___ ?
7_________ ___ ___ (Coords(s.get_safe_int("point_x"), s.get_safe_int("point_y")))
8_________ ___ ___ :
9_________ ___ ___ s.get_safe_Coords("point", extent)),
0_________ ___ s.get_int("area", 0)));

Modified local version which silences python checker:
1______m_player_area = Player_Area<Area<FCoords> >
2_________(s.get_Player_Number("player", map.get_nrplayers(), 1),
3_________ Area<FCoords>
4_________ (map.get_fcoords
5_________  (s.get_safe_int("version") == 1
6____________?
7____________(Coords
8____________ (s.get_safe_int("point_x"),
9____________  s.get_safe_int("point_y")))
0____________:
1____________s.get_safe_Coords("point", extent)),
2_________  s.get_int("area", 0)));

The first version is more consistent and enables using different tabwidth
settings. Second one is broken, I say. The python checker should flag
this, too.

Another thing that has me: In my above representation I count a total
width of exactly 80 on line 7, revision 3947 version, excluding line
number.

My editor (vim) does count the total for that same line as 78 on screen.
This is because the original tab char on position 15 is squeezed to 1 char
screen width. The python version does currently not respect this and flags
the line as erroneous. It would otherwise happily accept the first
version.

HTH,
Philipp