Re: a simple formatter

On Wed, 2008-02-13 at 13:52 +1300, Amos Jeffries wrote:

> 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.

I bet there are other files with problems. I doubt Christos verified
each and every source file.

> > 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.

Some of us actually prefer the above formatting!

> > 2) The if else formated as:
> >
> > if(...) {
> > }
> > else {
> > }
>
> Thats wanted yes?

Not all want this, but it is not a big deal anyway.

> > 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.

Agreed. And I think it would be fairly easy to disable that in code
since there is already a command line option that affects the behavior.
In fact, Christos, have you tried using "-cc 0"?

> 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.

Yes, needs checking.

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

What's wrong with that? I always use that style, I think.

> > 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 :-)

This will make class macros difficult to read, but not a showstopper.
Perhaps there are some /*magic_codes*/ that stop and resume formatting
in bcpp?

> > 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.

Ugly, but not a show stopper, IMO.

> > 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.

Agreed. Same as the one above. This one is probably easy to fix in the
sources.

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

I did not count any showstoppers for bcpp.

I doubt the rest is OK for astyle, and we should not forget that astyle
requires pre- and post-processing. It is likely that similar pre-post
processing or code modification can fix bcpp problems as well.

In general, I think astyle _quality_ is much worse (it actually breaks
valid programs), but bcpp is a dead project (last change - 2005/07/25)
and astyle does show signs of life once in a while.

I think the biggest question right now is whether Christos can confirm
that astyle (with pre- and post-processing) screws up only two source
files.

Thank you,

Alex.
Received on Wed Feb 13 2008 - 09:11:18 MST