I have a lot of Perl code. At work we have a lot of Perl code. I had to come up with a standard Perl style. It's not important that this is the best Perl style ever - instead it's important that this Perl style is good enough and this is the one I use with all my CPAN modules. I use Perltidy to reformat Perl code using the following .perltidyrc (mostly cribbed from Damian's in Perl Best Practices):
-l=78 # max line width is 78 cols -i=4 # indent level 4 cols -ci=4 # continuation indent 4 cols -st # output to STDOUT -se # errors to STDERR -vt=2 # maximal vertical tightness -cti=0 # no extra indentation for closing brackets -pt=1 # medium parenthesis tightness -bt=1 # medium brace tightness -sbt=1 # medium square bracket tightness -bbt=1 # medium block brace tightness -nsfs # no space before semicolons -nolq # don't outdent long quoted strings -wbb="% + - * / x != == >= <= =~ !~ < > | & >= < = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x=" # break before operators -ce # cuddled elses
You may use this too. Or pick your own. If you send patches to my modules, I'll run Perltidy on it and all the code will have the same style ;-)
Re:perltidy is sanctioned babel
btilly on 2007-09-19T01:07:39
The problem is that while the big decisions are obvious, the little ones are not. And there are lots of little decisions to make while formatting. While you can get people to agree on some of them, you can't get them to agree on all of them.
For example, based on your post you should not break before operators. However if you read Perl Best Practices, you'll find some excellent reasons given for why you should break before operators. Basically they have to do with how our eyes move when we skim through code, and they relate to something called the end weight problem.
So there is a difference, how do you resolve it? Well I'm willing to bet that Damian's thought a lot more about this topic than you have. I also find his reasons to be pretty good. But I'd not be surprised if you were willing to argue this particular point.
The result? Damian and you disagree on whether you should break lines before or after the operator. You have different personal opinions. We have three options. The first is that you can convince Damian. The second is that Damian can convince you. The third is that we have to live with the difference.
I guarantee that you're not convincing Damian. If you read Damian's book, he might convince you. But if you read Damian's book and you have strong opinions, I'd be shocked if you can't find another practice that you disagree with, that you won't convince him on. So now what? Oh right, you'll have to live with your differences.
Which is exactly the situation that you found so surprising.
Now there is a bigger reason for this, which is very non-obvious. I learned about it from Code Complete. And that bigger reason is that coding expertise is fragile.
Suppose we take someone who is familiar with a particular formatting style. Say, variable names are in CamelCase. You don't cuddle your braces. There is always a space between a paren and whatever is inside it. You use a 4-space indent. Now you plop them down in a code-base that is different. Variables names use_underscores. You cuddle your braces. You use a 2-space indent.
What happens?
Well it turns out that the transition is a shock. the constant minor changes interfere with that person's ability to achieve programming flow. It doesn't matter what the arguments pro or con for those differences are. It doesn't matter whether in the long run the new style might be slightly better. (Or not.) The immediate result is going to be that the programmer is suddenly much less productive. (Some people adjust easily. Some less so. Everyone has to work to adjust.)
And that is what really drives these religious debates. The reasons given for different styles are far less important than just having styles synchronize within a code base. But the decision you make is going to cause some people to win and some to lose.Re:perltidy is sanctioned babel
Eric Wilhelm on 2007-09-19T19:43:51
...coding expertise is fragile.... Suppose we take someone who is familiar with a particular formatting style. ... Well it turns out that the transition is a shock. Exactly. Like I said: babel. The conflict comes from the subtle differences.
And that is what really drives these religious debates.... I would rather than the debate be based in reason than religion (call it semantics, but "religious debate" is, by definition, a contradiction of terms.)
Given one internally consistent system, which is logically defensible, we would not be having this discussion and perltidy would not have options.
Re:perltidy is sanctioned babel
btilly on 2007-09-19T20:51:10
I would rather than the debate be based in reason than religion (call it semantics, but "religious debate" is, by definition, a contradiction of terms.)
Actually it is not a contradiction of terms. It is a description.
Debates happen. Both sides bring arguments to bear, and argue. But people wind up arguing past each other, and after a while it becomes apparent that the answers are hugely important to people, but they cannot logically justify that importance.
Because this is so reminiscent of debates over religion, we call debates with these characteristics, "religious debates". (With the subtext being that the One True Brace Style a matter of theology.)Given one internally consistent system, which is logically defensible, we would not be having this discussion and perltidy would not have options.
Oh how I wish you were right.
Unfortunately, if perltidy only offered one option, it would be ignored by all of the people who don't agree with that one option. It is only able to become popular because it is flexible.
And, truth be told, there is no one option that is right. For instance I already pointed out that there are good reasons to break lines before operators. However you can't do that in many languages (eg JavaScript, VB and Ruby), because they rush to end your line of code when you do that. So the ideal Perl style won't work in those languages.
The result? We're not about to see agreement on how to format code in our lifetimes.Re:perltidy is sanctioned babel
slanning on 2007-09-19T09:47:58
I must be the only person in the world who thinks it is absurd to see code formatting as a matter of personal preference.In French, it's conventional to put a space before the question mark -- like this ? They also don't seem to indent new paragraphs. ¡In Spanish, they mark exclamations at the front too! In Czech, we can see, that they put commas before "that" when the independent clause comes first (as in this sentence, so "we can see" isn't parenthetical). In German, they capitalize Nouns and sometimes in Phrases, extra Commas put.
So I think it's absurd that you think it's absurd that formatting is a preference.
:) (Though you could probably argue that those languages are consistent "internally", so picking a format for Perl would only be equivalent to picking it for one of those languages. Maybe programming languages each need a few hundred years to settle on formatting conventions.) Recently I've been experimenting a little with the formatting of my emails, as I don't like all of the "standard grammatical conventions for written text". For example,
Also, it takes frustratingly long for
any kind of change we make
to get into an actually-used version of Bricolage.
It was news recently that Emacs was having this problem,
and Debian notoriously had it. The result is that
people who at first anxiously add a feature to the project
subsequently lose interest as the feature sits there
practically forever
without seeing the light of day till years later.
We suffer badly from this.(So I was trying to put one "phrase" per line, with continuations indented by one space.) They end up looking almost like poems, which I think makes them too flippant. It doesn't mean I have to accept the standard conventions, though.
I wonder why we even use text and punctuation much any more in programming. I'd think it'd be nicer to abstract those things away. (What was that project whose name I can never remember, S*****y, where you program by plugging images together?) I guess we're used to typing keys on a keyboard, though, so editing text is easiest.
Re:perltidy is sanctioned babel
Eric Wilhelm on 2007-09-19T19:59:29
Though you could probably argue that those languages are consistent "internally", so picking a format for Perl would only be equivalent to picking it for one of those languages.Yes. And Perl is (quite arguably (on many levels)) linguistically based in English.
Maybe programming languages each need a few hundred years to settle on formatting conventions.Maybe, but please name some French/ Spanish/ German/ Czech programming languages.
(So I was trying to put one "phrase" per line, with continuations indented by one space.) They end up looking almost like poems, which I think makes them too flippant.Poems yes, but "poem" does not imply "flippant". Poetry has been quite influential throughout history (though we forget that thanks to technological advances like "fox news".) Poems are memorable because of the rhyme (or non-rhyme), beat, linebreaks, syntactical twists, etc. It's not much different than distending an array/hash declaration across multiple lines (in a tabular form), or adding breaks between chunks of statements within a block.
Re: perltidy is sanctioned babel
Maddingue on 2007-09-20T14:21:34
Maybe, but please name some French/ Spanish/ German/ Czech programming languages.Rasmus Lerdorf (Denmark) designed PHP.
Bjarne Stroustrup (Denmark) designed C++.
Guido van Rossum (Netherlands) designed Python.
Yukihiro Matsumoto (Japan) designed Ruby.
Niklaus Wirth (Switzerland, german part) designed ALGOL, Pascal, Modula.
Jean David Ichbiah (France) designed Ada.
The Ericsson company (Sweden) designed Erlang.
French professors designed Prolog.
Norwegian professors designed Simula.
INRIA (France) designs OCAML.
etc, etc.
I could go through the thousands of programming languages listed in Wikipedia, but stil have some
$workto do:-)
Wow!!
grinder on 2007-09-19T11:27:43
I'm impressed!
Did anyone ever tell you that you have too much time on your hands?:)
Re:Wow!!
Relipuj on 2007-09-19T21:28:50
man, you'd see my other config files and you'd say it took me several years to get them like they are... wait, it took me several years to get them like they are...
if you want some here's a list of my must have (they're in/etc/skel/ when i finish installing a new distribution):
-.bashrc
-.dircolors (very exhaustive)
-.fvwm/* (minimal theme)
-.indent.pro
-.inputrc (works good with a lot of apps)
-.links/links.cfg
-.lynxrc
-.mc/ini (with undocumented functions)
-.perlconsolerc
-.perlcriticrc
-.perltidyrc
-.screenrc
-.toprc
-.vimrc
-.Xmodmap (mapping keys from multimedia keyboards)
-.xrbd/xterm.xdefaults (because xterm is enough to run screen...)
If you are interrested in some just tell me, i'll post them here (or make an archive and post it somewhere if you want everything)Re:Wow!!
steph on 2007-09-21T09:19:20
yep. I am. Thanks
Re:Wow!!
Relipuj on 2007-09-22T22:56:21
heh, in fact i wasn't really expecting someone to reply, yet you did. Give me a few days to comment the configurations files (when possible) and i'll post them back here, or in a.bz2 file somewhere on the net. Let's say next Sunday (sept. 30) you'll get all the files.
I just ask for the delay to clean up my config directory, it's a real mess in there and i don't have the time to sort everything right now.Re:Wow!!
steph on 2007-09-24T09:02:13
Take your time. I asked because I was curious to see how people organize their things. Lately I seem to waste time in simple yet important tasks with a net result of less time to code
cheers --stephan:(. Having a working (and portable) set of config files is certainly an asset.
You could shorten this by invoking all of the Perl Best Practice options using -pbp or --perl-best-practices.
John.
--
