On 2009-09-23 09:36-0000 andrewr...@users.sourceforge.net wrote: > Revision: 10457 > http://plplot.svn.sourceforge.net/plplot/?rev=10457&view=rev > Author: andrewross > Date: 2009-09-23 09:36:41 +0000 (Wed, 23 Sep 2009) > > Log Message: > ----------- > Large patch to standardise the coding style in src/ using uncrustify. This is > entirely cosmetic with no code changes. > > This required a small amount of hand editing of multi-line #define > statements. Now this has been done you can safely run uncrustify again > without upsetting the results.
Hi Andrew: I have been looked at your src uncrustify changes using the coloured diffs I mentioned, and I noticed some peculiarities. I was going to give you a complete list of what I noticed, but I stopped part way through because I think we have to deal with the ugly split line issue before going further with this. ltdl_win32.c: Is there a real logic change here? At the end of the code there used to be an else followed by a blank line followed by return NULL; Now the blank line is gone. I frankly don't know whether all C compilers would have ignored that blank line or not, but I thought I had better bring this potential logic change to your attention in case you think something needs to be done. pdfutils.c: in two places code involving realloc has ugly splits. plarc.c: ugly splits of plarc_approx and c_plarc definitions. plargs.c: ugly splits of ParseOpt and ProcessOpt declarations and definitions, the definition of GetOptarg, some of the fprintf's, snprintf's, and scanf's, and many of the mallocs. I stopped looking at plargs.c because of the bad line splitting issue. To my mind, ideal splitting of overlong lines would be the minimum that gives lines which are not overlong with a small amount of indentation for each line that has been split from the first. Instead, uncrustify splits overlong lines into tiny bits and pieces with large indentation that makes the code extremely difficult to read. What do you think of the idea of reverting plargs.c and using that source code as a test case for tweaking uncrustify.cfg parameters until we get more reasonable line splitting? Once that is achieved, then we could revert the present changes to the equivalent of revision 10456 and uncrustify that without all the ugly split lines. 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 __________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
