Приглашаем посетить
Дмитриев (dmitriev.lit-info.ru)

Section 2.1.  Bracketing

Previous
Table of Contents
Next

2.1. Bracketing

Brace and parenthesize in K&R style.

When setting out a code block, use the K&R[*] style of bracketing. That is, place the opening brace at the end of the construct that controls the block. Then start the contents of the block on the next line, and indent those contents by one indentation level. Finally, place the closing brace on a separate line, at the same indentation level as the controlling construct.

[*] "K&R" are Brian Kernighan and Dennis Ritchie, authors of the book The C Programming Language (Prentice Hall, 1988).

Likewise, when setting out a parenthesized list over multiple lines, put the opening parenthesis at the end of the controlling expression; arrange the list elements on the subsequent lines, indented by one level; and place the closing parenthesis on its own line, outdenting it back to the level of the controlling expression. For example:


    my @names = (
        'Damian',    
# Primary key
'Matthew',
# Disambiguator
'Conway',
# General class or category
); for my $name (@names) { for my $word ( anagrams_of(lc $name) ) { print "$word\n"; } }

Don't place the opening brace or parenthesis on a separate line, as is common under the BSD and GNU styles of bracketing:

    # Don't use BSD style...
    my @names =
    (
        'Damian',    # Primary key
        'Matthew',   # Disambiguator
        'Conway',    # General class or category
    );

    for my $name (@names)
    {
        for my $word (anagrams_of(lc $name))
        {
            print "$word\n";
        }
    }

    # And don't use GNU style either...

    for my $name (@names)
      {
        for my $word (anagrams_of(lc $name))
          {
            print "$word\n";
          }
      }

The K&R style has one obvious advantage over the other two styles: it requires one fewer line per block, which means one more line of actual code will be visible at any time on your screen. If you're looking at a series of blocks, that might add up to three or four extra code lines per screen.

The main counter-argument in favour of the BSD and GNU styles is usually that having the opening bracket[*] on its own line makes it easier to visually match up the start and end of a block or list. But this argument ignores the fact that it's equally easy to match them up under K&R style. You just scroll upwards until you "bump your head" on the overhanging control construct, then scroll right to the end of the line.

[*] Throughout this book, the word "bracket" will be used as a generic term to refer to any of the four types of paired delimiters: "braces" ({...}), "parentheses" ((...)), "square brackets" ([...]), and "angle brackets" (<...>).

Or, more likely, you'd just hit whatever key your editor uses to bounce between matched brackets. In vi that's %. Emacs doesn't have a native "bounce" command, but it's easy to create one by adding the following to your .emacs file[Section 2.1.  Bracketing]:

[Section 2.1.  Bracketing] The editor configurations suggested throughout this book are collected in Appendix C, Editor Configurations. They are also available to download from http://www.oreilly.com/catalog/perlbp.

    ;; Use % to match various kinds of brackets...

    (global-set-key "%" 'match-paren)
      (defun match-paren (arg)
        "Go to the matching paren if on a paren; otherwise insert %."
        (interactive "p")
        (cond ((string-match "[[{(<]"  next-char) (forward-sexp 1))
              ((string-match "[\]})>]" prev-char) (backward-sexp 1))
              (t (self-insert-command (or arg 1)))))

More importantly, finding the matching brace or parenthesis is rarely a goal in itself. Most often you're interested in the closing bracket only because you need to determine where the current construct (for loop, if statement, or subroutine) ends. Or you want to determine which construct a particular closing bracket terminates. Both those tasks are marginally easier under K&R style. To find the end of a construct, just look straight down from the construct's keyword; to find what construct a particular bracket terminates, scan straight up until you hit the construct's keyword.

In other words, the BSD and GNU styles make it easy to match the syntax of brackets, whereas K&R makes it easy to match the semantics of brackets. That being said, there is nothing wrong with the BSD or GNU styles of bracketing. If you, and your fellow developers, find that vertically aligned brackets improve your comprehension of code, then use them instead. What matters most is that all the members of your programming team agree on a single style and use it consistently.

    Previous
    Table of Contents
    Next