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.