Laurent Laborde wrote:
Friendly greetings (again) ! I'm planning to patch all perl file in the postgresql source tree. But i can't find any rules other than : set tabstop=4 shiftwidth=4 noexpandtab
As I posted elsewhere, use perltidy <http://perltidy.sourceforge.net/> to format the code according to standard postgres conventions thus:
perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm
It could be nice to define the perl coding style of postgresql somewhere on a wiki. Here is a few questions : - What is the oldest perl version that we should support ?
Nothing earlier than 5.6, certainly.
- Do we use the sames rules for "tools" and "contribs" (eg : use strict) ?
Yes. The two major uses we currently have for perl are to create psql's help, and the MSVC build system. These are important enough that they should be tolerably sane. But so should any tool, really.
- is there any obvious rules other than "use strict" ?
not that I can think of.
- Should we support Win32 platform in perl tools use by developpers (eg : check_keywords.pl) ? (that include the "\" vs "/" problem in file path)
Use of forward slash / in file paths is not a problem on Windows. See the the buildfarm script <http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl?rev=1.102&content-type=text/x-cvsweb-markup> which runs happily on Windows and doesn't use backslash in file paths at all.
- What about dependencies of external perl modules ?
Avoid them unless they are standard modules that should ship with any sane perl distribution. We've had trouble in the past even with things one might expect such as ExtUtils::MakeMaker. If it's not listed in "perldoc perlmodlib" then don't use it.
- I'm used to heavily comment my code... should i do that here too ?
Not to the point of silliness. But if something isn't obvious then explain it.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
