While no doubt well meant, the subject of coding style has enough opinions that it is usually referred to as a 'religious war', comparable to one's choice of editor or operating system. Thus, in polite society (hopefully The Monastery is included in this definition), one usually soft-pedals any discussion of said 'delicate' subjects -- or even doesn't mention them at all.

To put it another way, there's no 'nice' way to discuss bracing style -- it's just a matter that we're going to have to agree to disagree on.

And that's really all I can say.

I will say, the one concrete thing (as opposed to just preference) I like about having the { on the same line of a sub or an if:

If it's a longer sub or if block, and I'm at the closing }, I can hit % in vi, and it takes me to the matching one. If it's on the same line, I see the sub name or conditional on the screen, which is _exactly_ what I want. If it's on the next line, I have to then scroll up a line to see, and the next thing I'm usually going to want to do after seeing that is % back to the end brace (to go back to where I was.) So, it annoys me to no end when people put them on the next line.

If it's a longer sub or if block, and I'm at the closing }, I can hit % in vi, and it takes me to the matching one. If it's on the same line, I see the sub name or conditional on the screen, which is _exactly_ what I want. If it's on the next line, I have to then scroll up a line to see, and the next thing I'm usually going to want to do after seeing that is % back to the end brace (to go back to where I was.) So, it annoys me to no end when people put them on the next line.

Can't you just rebind the % key so that (in addition to what it usually does) it checks that the line it is on is not the first or last line in the buffer, scrolling one line if necessary to accomplish that? vim fans claim it's pretty customizable, so one would think that would be easy (though, not being a vi user myself, I'm speculating here).

(Of course, I prefer the behavior wherein the editor shows the line containing the opening brace in the status area when your cursor rests after the closing brace, so you don't have to hit a key in the first place, which brings us back to your argument, since there's not room in the status area for two lines without expanding it, which is a bit jarring.)

My own reason for preferring nestled braces in most cases is that it makes the code significantly more vertically compact, which allows a lot more context to fit on the screen at once, making the code easier to follow, since you can see more with less scrolling about.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Ahhh, at last a reason for K&R indentation (albeit a bit cart before the horse).

---

Food for thought, not fuel for flames.

• Is your code documented and commented?
• Does your code have a reasonable interface? Have you separated concerns?
• Does your code have a test suite? Do you use it?

I think that:

is very wishful thinking. Coding styles always generate differing points of view. It is as taboo a subject as religion or politics.

A very quick SuperSearch shows:

• Perl Style Guides for Large Projects
• Perl style question: loops with postcondition
• Why do Perlers hate C-style for-loops, especially when they're called for?
• Rules of Proper Perl Style
• etc.

While working on the B language, K&R realized that cyrillic character sets have no curly-brace. Further, there is no tab character Therefore, a language that was to catch on in the West should rely heavily on this syntax in order to stop Godless Communists from using it.

Not only did K&R use this syntax, but they also suggested a bracing style that was difficult to use on commie terminals:

sub y
{
        $h = shift;

        if( $b ) {
                # code
        }
        elsif( $t ) {
                # code
        }
}
[download]

As you can see, the key block, sub, places the brace on the next line. This is because Russian terminals were only 7 lines high, which was forced by Stalin's 1957 decree. With this style in hand, only 5 other lines were visible. The effectiveness can be increased through the use of plentiful vertical whitespace.

However, modern corruption of the programming field has led to the development of languages that forsake this important, commie-fighting syntax.

That is far and away the most compelling justification for K&R indentation I have heard. Wish I could give it more than one vote!

---

Food for thought, not fuel for flames.

Just a few days ago we had a discussion about the same subject.

Have a look at it. There are plenty of internal and external links to satisfy your needs.

Oh lord. Not the "one true brace style" argument again :-)

Learning to use perltidy and learning to compromise on something that the whole team can agree on would be my advice.

If you ever have to use another form of indentation for long enough to become used to it, I predict that you'll discover that your present preference is entirely due to this fragility. You mentally block code based on the indentation style, and facing an unfamiliar indentation style you need to start thinking about that, which gets in the way of everything else that you do.

However there are other people who would have exactly the same issue with how you indent code.

BTW about commenting, if you really put comments on every block, you're probably overdoing it. Remember, comments start with as many bugs as code does, but bugs in code get fixed. And code tends to be better maintained than comments. Therefore if your comments reiterate what your code does, then experienced programmers are likely to ignore the comments.

The mantra is to make the code, as much as possible, its own comment. You do this with well-chosen variable names, function names, and so on.

Does that mean that you can remove comments? Of course not. But in the long run I've found, as I0 put it once, I find the most useful comments state what remains invariant, while the code states what gets transformed. In that way comments document what you need to know when editing the code, but changes to the logic are less likely to require re-writing comments.

A relevant thread is Re (tilly) 2 (disagree): Another commenting question,. As I always point out when I bring up this thread, the thread was accompanied by a private chat between me and DeusVult. The tone of the thread was far more confrontational than the chat, so this thread doesn't really capture the actual tone of the full conversation. But still it is worthwhile reading.

Excellent reply. Thank you for the links. I guess you recommend Code Complete? :-)

I agree fully with your comments about comments and names, and indentation actually too. Our experience is indeed that programming expertise is fragile (legacy K&R formated code in our software really slows us down).

No, I don't comment each block as illustrated. On reflection that was a rather illustration. Hey-ho.

---

Food for thought, not fuel for flames.

but cperl-mode supports several styles, do you know about M-x cperl-set-style???

By that argument, would lack of indentation qualify as consistent use?

Personally, I use what makes sense to me. I never focused on a particular style until I learned to write LPC, and I still write my Perl that way. (trust me -- it's better than how I learned to format Perl, as I came from a BASIC, Logo, Pascal and FORTRAN before that).

As things go, I think that screen size and editor choice play a rather significant role in what someone's preferred style. Someone who learned to program on a 12 line high screen, or through a dumb terminal is going to think differently than someone who started programming with a 21" monitor on their desk. Likewise, someone who started out in ex/ed, or some other line editor is going to work much different from someone who worked in DOS EDIT, or BBEdit, or whatever else the popular editors are these days.

I'm personally okay with just about anything, because I'll just reflow it. (which works up until I'm trying to submit patches, in which case I have to save my initial reformatted version, so I can diff that and the final, then re-apply the changes with the author's style of formatting back to the original. For the most part, I'm happy with whatever I'm given -- it's normally enough for me that people have gone out of their way to give their code at all, I'm not going to be overly picky about how many spaces are in it.

It doesn't matter what style of indentation you use. As long as you use it consistently.

If by "consistently" you mean "always the same way", then I actually disagree with this, at least to some extent. It is my considered opinion that good indentation style takes into consideration the semantics of the code being indented. Sometimes I put up to three "statements" (things between semi-colons) on the same line, if what they are doing is sufficiently related that it enhances, rather than impedes clarity, and indeed, that can make a block rather compact...

  if (condition) { $foo=0; $bar++; }
[download]

But I certainly wouldn't recommend doing *all* conditional blocks that way. Also, sometimes I put something after a closing brace, on the same line, but only if what it's doing is related to the closing of the block, as in...

open FOO, '<', $filename;
while (<FOO>) { chomp;
   my ($bar, $baz, $quux) = $_ =~ /someregex/;
   push @quux, [$foo, $baz, $quux] if $quux;
} close FOO;
[download]

But again, I certainly wouldn't recommend always putting code on the same line after the closing brace. If it weren't logically related to the closing of the block, that could get very confusing. If I had to distill this to a general principle, it would be, take the code's semantics into consideration when deciding how much whitespace to use and where to use it.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

No, I don't mean "always the same way." I'm talking about avoiding inconsistent indentation style like:


if (condition)
{
  code;
    other_code;
}
else {
   bork; }

if (condition_2) {
  foo;
}
else
  {
  i_think_you_get_what_i_mean();
  }
[download]

I don't peronsally mind if a block is on one line, as long as it's short. if (condition) { $foo=0; $bar++; } is perfectly fine. I mean consistency within a file, given the context. If you always put short blocks on one line, great. If you do something like


if (condition) { $foo=0; $bar++ }

# more code...

if (other_condition) {
    $foo++;
}
[download]

then I consider it to be inconsistent. And when I find inconsistent indentation it implies to me that your thinking isn't clear. This may or may not be the case -- it's more of an impression I get than an absolute rule.

I won't get into the "reasons" for my preference because they are all subjective, and decades of history have proven that this discussion is futile.

Coming soon: why cherry ice cream sucks and chocolate ice cream rules!

Oh, I agree, chocolate ice cream rules (esp. with chocolate covered peanuts).

---

Food for thought, not fuel for flames.

And I personally don't find it helpful to have open and close curlies line up vertically. I find it very annoying to scroll to some point in a file and see something like

   {
      ...do something...
      .
      .
   }
[download]

But, as many others have pointed out, that's all a matter of religion¹. So to actually add something useful to this topic, I'll assert that everyone should try out a couple of different styles. And not just for a file or two. Personally, I have to stick to a style for about a month to get through the full set of phases:

1. disgust and revulsion
2. grudging acceptance and understanding of how the lunatics who use that style are able to make sense and extract value out of it
3. enthusiastic and wholesale adoption of the style for yourself, together with disbelief at how mired you were in your ridiculous old style
4. (this one usually comes after going back to editing one of your old projects) complete reversal -- wonderment at how you could possibly have found that new style any good. Sure, it has its advantages, but your original style is just so much better.
5. and finally: integration, when you merge parts of the old and new together to make something that is more like one than the other, but takes parts from both.

After I (unwillingly) went through a couple of those series of phases I listed above, I actually found it very liberating to be able to shift between styles fluidly to match whatever existing code I encountered. There are too many barriers to working with other people's code already: programming language, NIH syndrome, portability, licensing, .... You do not want style to be yet another one.

Open source projects are great for this, since there are undoubtably several out there that interest you for personal reasons, and aren't written in your preferred style.

¹ And what's the one thing that all religions have in common? That's right, they all hold that they are right and all the rest are wrong.

² On the other hand, this helped my typing speed immeasurably. Whoever could type faster would be able to gradually convert the codebase to the One True Style.

Good points well made.

I realise that some people would have the {} belong to the enclosing statement. There is a compelling argument for them being part of the block, but I won't go into that here :-). That is about the point that religion enters.

The first three people who worked on our code base had pretty compatible styles. Later additions to the team have had divergent styles. In general that's ok so long as they use their style in their new code, but it becomes a real pain when they start editing old code and convert parts of it to a radically different style. K&R and Whitesmiths just don't go together (see Indentation styles).

---

Perl is Huffman encoded by design.

if ($x) {
    if ($y) {
        code;
    }
    code;
}
else {
    code;
}
[download]

if ($x) { code; }
[download]

code if $x;

long section of code
    if long test on $x;
[download]

if ($x)
    {
    code;
    }

if ($x)
    { code; }
[download]

Howdy!

youForgotToCamelCaseItSoYouCanBeCompliantWithTheOneTrueJavaSymbolNamingConvention

yours,
Michael

Here we go again...