Re: a simple formatter

> Some comments about astyle and bcpp formatters. Also I am attaching a
> new script which solves the problems mentioned by Amos.
>
>
> Astyle:
> Looks that it is difficult to fix all problems of astyle.....
> Looks that the "#ifdef...#else ..." confuses the astyle. For example is
> not possible for me to format well the src/tools.cc and src/stat.cc
> files.
> However with formater.pl script looks that the formated source code is
> correct (but in some cases not well formated).
>
>
> The bcpp in the other hand looks that it does not breaks the code and
> has more predictable behaviour. But still is not excellent.....
>

Given all the problems below. Would it be easy enough to get the bcpp
problems sorted out as bugs and use the fixed version?

Or is it possible to omit the src/tools.cc src/stat.cc files from astyle
until they can be cleaned manually to work better.

> It changes the current indentation format of squid3 as follows:
>
> 1) The class definitions have the following format:
>
> class aclass
> {
> public:
> void a func()
> .....
> };

I suppose we could live with that if it was automatically done.

>
> 2) The if else formated as:
>
> if(...) {
> }
> else {
> }

Thats wanted yes?

> 3) When there are comments with code in aline the bcpp will try to ident
> the comments. For example
> i++; /*a comment*/
>
> converted to:
> i++; /*a comment*/
>
> There is a command line parameter the -cc which defines in which column
> the comments will be placed. You can not tell to bcpp to not format the
> comments.

We could live with this I think in small comments.

Does it still do that if the comments are seperate from code lines? I'm
thinking how would this affect the longer comments and auto-docs comments
might be a problem.

>
> 4) The function calls which placed in more than one line formated as:
>
> afuctioncall(arg1,arg2,.....
> argn..................);
>

weird. that would need fixing.

>
> 5) Does not indent the multiline preprocessor macros:
> #define GENGRAPH(X,Y,Z) \
> GRAPH_TITLE(Y,Z) \
> GRAPH_PER_MIN(X) \
> GRAPH_PER_HOUR(X) \
> GRAPH_END
>

aha. nice reason to get rid of those macros sooner :-)

>
> 6) When a function/method definitions takes more than one lines does not
> formated well:
>
> void aclass::afunction (int a, int b
> int c,ind);

should not need to care about line length. but this is a naasty one anyway.

>
> 7) For the constructors it uses the following format (does not indent
> data members) :
>
> aconstructor::aconstructor(....):
> data1(...),
> data2(...),
> data3(...),
> {
> }

Another thing we could possibly live with.

So
  bcpp: 1-OK, 3-PASSABLE, 2-BAD
vs
  astyle: 2 problem files. rest OK.

Amos
Received on Tue Feb 12 2008 - 17:52:48 MST