NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
perltidy is sanctioned babel (Score:1)
If
I just ( you know , like this )
format my English text in any old way,it
gets awfully hard to read.There are standard grammatical conventions for written text,yet we try to reinvent them for programming
. See how silly it is to break before the operator
?And what's the deal with braces being non-tight
? ( I mean, we don't have space after an opening paren ( and
Re:perltidy is sanctioned babel (Score:1)
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.
Reply to This
Parent
Re: (Score:1)
Exactly. Like I said: babel. The conflict comes from the subtle differences.
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 i
Re: (Score:1)
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 r