On 2009-07-13 10:01+0100 Andrew Ross wrote: > On Sun, Jul 12, 2009 at 01:21:55PM -0700, Alan Irwin wrote: >> Well, we still need that style-conscious volunteer, but to get the ball >> rolling I just committed uncrustify.cfg in the top-level source tree which I >> think already does a pretty good job of enforcing the consensus style >> we have been discussing. >> >> uncrustify-0.53 has a number of example style files including the default >> style, defaults.cfg (which defines some 350 options). One of those style >> files is ben2.cfg which is the favorite style of the author of uncrustify. >> It only mentions ~60 options so I assume those are the most >> important options, and the code uses defaults.cfg for the rest. I >> edited ben2.cfg to create uncrustify.cfg. >> >> You can run it like this: >> >> ~software/uncrustify/install/bin/uncrustify -c uncrustify.cfg -f \ >> drivers/qt.cpp |less >> >> where the application pathname must point to the (latest) 0.53 version of >> uncrustify. I adjusted uncrustify.cfg following the documentation in >> defaults.cfg until the results looked consistent with what was mentioned on >> list. In addition to using less to view stdout, I have also used the >> programme to create a local "styled" form of qt.cpp which builds without >> issues. >> >> However, when looking at the "styled" source code I noticed that line >> breaking on one ugly long line starting with >> >> static DrvOpt qt_options >> >> gives an even uglier (but still correct) result. I presume it is the >> combination of alignment options (which I didn't change from Ben's version) >> which need tweaking here. Anyhow, uncrustify.cfg needs some more work >> following the documentation in defaults.cfg (from uncrustify-0.53), and >> patches or commits to that effect would be most welcome. > > Alan, > > This looks like a power full tool that should do what we want. Things I > noticed from a quick check of the output. > > 1) It's very free with spaces at the moment, for example aligning the = > sign where you have a series of variable assignments. (Not necessarily > a criticism, but a comment and a potential change of style.) > > 2) It adds spaces in between function names and brackets, e.g. > sin ( x ) not sin(x). I don't particularly like a space before the ( > since I think it can make it less clear that sin is a function rather than > a variable at a quick glance. I don't mind the spaces inside. Particularly > with lots of arguments I think this is a good idea. > > 3) It doesn't at the moment fix up C comments with * to our "style", or > at least consistently. > > I suspect that line breaks will always be to some degree a subjective > problem depending on the precise code and so any automated system might > not do exactly what you would have done. > > All these can, I'm sure, be fixed. I've only tried on C / C++ code.
Hi Andrew: Thanks very much for having a look at the style result from this initial version of uncrustify.cfg. I agree with you on 1). There are some 45 (!) *_align_* variables to play with (see uncrustify-0.53/etc/defaults.cfg which documents them but also turns them all off by default). Frankly, I am not sure whether we want any alignment style at all. The variables I chose to turn on just matched the uncrustify developer's favorite ones as an experiment. If you agree we don't want this, just remove all the *align* variables from uncrustify.cfg (which may fix up the ugly but syntatically correct result I noticed when trying to style a line that was originally an ugly long one.) I agree with you on 2). Try sp_func_proto_paren, sp_func_def_paren, and/or sp_func_call_paren to fix this. I will leave 3) to your best judgement. There appears to be some 20 variables dealing with comment style. Here are a few of them I noticed which might be a help. # Whether to put an empty '/*' on the first line of the combined c-comment cmt_c_nl_start = false # false/true -- # Whether to put an empty '/*' on the first line of the combined cpp-comment cmt_cpp_nl_start = false # false/true -- # Whether to put a star on subsequent comment lines cmt_star_cont = false # false/true -- # The number of spaces to insert at the start of subsequent comment lines cmt_sp_before_star_cont = 0 # number -- # The number of spaces to insert after the star on subsequent comment lines cmt_sp_after_star_cont = 0 # number But look for "cmt_" in defaults.cfg if these options are not enough. uncrustify is obviously a tremendously versatile code styling tool, but it is going to take some additional experimentation as suggested above following the documentation in defaults.cfg to satisfy all our styling needs. Since your eye for style issues is much better than mine, I encourage you to go ahead and make the necessary changes to uncrustify.cfg. I also suggest while doing so you concentrate just on C++ style issues to make the problem tractable. We can deal with C (and possibly also Java and D) later after a satisfactory C++ style result has been produced. Once you are reasonably happy (via browsing through the results without actually changing any files) with the style produced by uncrustify.cfg for our C++ source files, then the next two tasks are to (1) test that uncrustify styling produces no changes in object files for all our C++ source, and (2) (assuming it passes that test) actually do the style changes and commit the results for our C++ source. The uncrustify -F option (which allows you to conveniently specify a list of files to be processed) should help for both tasks. I would be happy to implement automated scripts for (1) and (2) since I presume this process will need to be repeated from time to time. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
