Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Date: 2012-06-16 02:45:16
Message-ID: 20120616024516.GC26006@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2012-06-16 02:48:27 Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Previous Message Bruce Momjian 2012-06-16 02:43:36 pgsql: Update pgindent Perl indentation instructions based on feedback

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-16 02:48:27 Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Previous Message Jeff Janes 2012-06-16 02:07:00 Re: Resource Owner reassign Locks