Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3 - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3 |
Date | |
Msg-id | 20120616024516.GC26006@momjian.us Whole thread Raw |
In response to | Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3 (Noah Misch <noah@leadboat.com>) |
Responses |
Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3 |
List | pgsql-hackers |
On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote: > On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote: > > What about something like this in the root of the tree: > > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix > > > > There are files all over the place. The file that would most be > > affected with one run of this is the ECPG grammar generator. > > > > I checked the "-et=4" business (which is basically entab). We're pretty > > inconsistent about tabs in perl code it seems; some files use tabs > > others use spaces. Honestly I would just settle on what we use on C > > files, even if the Perl devs don't recommend it "because of > > maintainability and portability". I mean if it works well for us for C > > code, why would it be a problem in Perl code? However, I don't write > > much of that Perl code myself. > > +1 for formatting all our Perl scripts and for including -et=4. Since that > will rewrite currently-tidy files anyway, this is a good time to audit our > perltidy settings. > > Why -l=100 instead of -l=78 like our C code? > > perltidy changes this code: > > for ($long_variable_name_to_initialize = 0; > $long_variable_name_to_initialize < $long_limit_variable_name; > $long_variable_name_to_initialize++) > { > > to this: > > for ( > $long_variable_name_to_initialize = 0; > $long_variable_name_to_initialize < $long_limit_variable_name; > $long_variable_name_to_initialize++ > ) > { > > Using -vtc=2 removes the new trailing line break. Additionally using "-vt=2 > -nsak=for" removes the new leading line break, but it also removes the space > between "for" and "(". Anyone know how to make perltidy format this like we > do in C code? > > Why -naws? I would lean toward "-aws -dws -pt=2" to change code like this: > > -my $dbi=DBI->connect('DBI:Pg:dbname='.$opt{d}); > +my $dbi = DBI->connect('DBI:Pg:dbname=' . $opt{d}); > > I'd also consider -kbl=2 to preserve runs of blank lines that the author used > to delineate related groups of functions. OK, based on this feedback, I have updated the pgindent README to use these Perl indent instructions: find . -name \*.pl -o -name \*.pm | xargs perltidy \ --backup-and-modify-in-place --opening-brace-on-new-line\ --vertical-tightness=2 --vertical-tightness-closing=2 \ --nospace-after-keyword=for--nospace-for-semicolon \ --add-whitespace --delete-old-whitespace --paren-tightness=2 \ --keep-old-blank-lines=2 --maximum-line-length=78 \ --entab-leading-whitespace=4 --output-line-ending=unix Unless I hear otherwise, I will run this new command on the 9.2 and HEAD Perl files. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
pgsql-hackers by date: