perlcritic and perltidy
От | Andrew Dunstan |
---|---|
Тема | perlcritic and perltidy |
Дата | |
Msg-id | a2f2b87c-56be-c070-bfc0-36288b4b41c1@2ndQuadrant.com обсуждение исходный текст |
Ответы |
Re: perlcritic and perltidy
|
Список | pgsql-hackers |
The attached patch allows a clean run from the following script adapted from pgperltidy: { find . -type f -a \( -name '*.pl' -o -name '*.pm' \) -print find . -type f -perm -100 -exec file {} \; -print \ | egrep -i ':.*perl[0-9]*\>' \ | cut -d: -f1 } \ | sort -u | xargs perlcritic --exclude ProhibitLeadingZeros The changes are * disable perlcritic on Gen_dummy_probes.pl, since it's generated code from s2p * protect a couple of package declarations in plperl code from perltidy since it splits the lines and renders the 'no critic' directives there useless * mark a string eval in Catalog.pm with 'no critic', since it's clearly necessary. We should probably set up a policy file for perlcritic that turns off or at least lowers the severity of the ProhibitLeadingZeros policy. Making it severity 5 seems a bit odd. w.r.t. perltidy, I note that our policy has these two lines: --vertical-tightness=2 --vertical-tightness-closing=2 I've been looking at syncing the buildfarm client with our core code perltidy settings. However, I don't actually like these two and I've decided to exercise some editorial discretion and not use them. Note that the perltidy man page does suggest that these can make things less readable, and it also states unequivocally "You must also use the -lp flag when you use the -vt flag". That is the --line-up-parentheses flag and it's something we don't use. Enabling it would generate about 12k lines of diff. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: