Index: [Article Count Order] [Thread]

Date:  Sat, 29 Apr 2000 00:58:37 +0900
From:  firo@....jp
Subject:  [XP-jp:00314] 【 4.  Code Formatting 】 (案)
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <3909B74A.2EE2501F@....jp>
Posted:  Sat, 29 Apr 2000 01:07:40 +0900
X-Mail-Count: 00314

矢崎です。

4.  Code Formattingの翻訳案です。
間違いのご指摘等お待ちしております。

------------------------------
[Code Formatting]

ここに述べるのは、私たちが用いているコード・フォーマッテ
ィングのパターンの主要なものです。それらの名前や、例の
いくつかは、Kentの本からとりました。

** Inline Message Pattern **

メソッドの最初のメッセージに用いられるパターンは、いつも1
行に書いて、決してインデントしないというものです。

** Indented Control Flow **

注意。下にあるコード例のタブは、実際のコードよりも大きく取ら
れています。私はまだ、HTMLで、やりたいようにやる術を心得て
いません。

ゼロあるいは1つのアーギュメントを取るメッセージは、そのメッ
セージのレシーバと同じ行に書きます。

                foo isNil.

                2 + 3. a < b ifTrue: [...]

2つあるいはそれ以上のキーワードを持つメッセージは、1行目に
レシーバを書き、その下の行に、1つのキーワードとアーギュメント
のペアで1行ずつ取る形で続けます。キーワードとアーギュメントの
行は、レシーバの位置から1回のタブでインデントします。

                size > 0
                    ifTrue: [ ... ]
                    ifFalse: [ ... ]

                array
                    at: 5
                    put: #abc

                aCollection
                    copyFrom: 1
                    to: aString size
                    with: aString
                    startingAt: 1

ブロックは、開始ブラケットは、上方の左端に書き、終了のブラケッ
トは、下方の右端に書きます。ブロックの中について、他のルールを
適用します。その結果、ブロックが1行になる場合もあれば、複数
行になる場合もあります。

                ifTrue: [self recomputeAngle]

                ifTrue: [^angle*90 + 270 degreesToRadians]

                ifTrue:
                    [self clearCaches.
                    self recomputeAngle]

                ifTrue:
                    [self
                        at: each
                        put: 0]

同じオブジェクトに対して、ゼロまたは1つのアーギュメントを取る
メッセージが複数送られる場合、カスケードします。
(矢崎注:カスケードとは、メッセージの直列化のこと。間にセミコ
ロンをいれてメッセージを並べて書く。)

                self listPane parent
                    color: Color black;
                    height: 17;
                    width: 11

複数のアーギュメントを取るメッセージでは、カスケードしないこと。
カスケードすると、コードが読みにくくなります。例えば、height:width:
が1つのメッセージだとした場合、以下のようには書かないこと。

                self listPane parent
                    color: Color black;
                    height: 17
                    width: 11

以下のように書きましょう。

                self listPane parent color: Color black.
                self listPane parent
                    height: 17
                    width: 11

以下のように書けば、さらによいでしょう。

                | parent |
                parent := self listPane parent.
                parent color: Color black.
                parent
                    height: 17
                    width: 11

今まで述べたようなルールを使った結果が、醜いコードになって
しまったら、本当に必要なことは、メソッドをリファクタすることであ
るという状況にきています。フォーマッティング・ルールに疑問を
抱かないように。コードに疑問を持つようにしましょう。以下はそ
の例です。

               removeStep
                    | stepToRemove |
                    stepToRemove := self list selection.
                    stepToRemove isNil ifFalse: [stepToRemove isExecutable ifTrue:
                        [self list remove: stepToRemove.
                        steps remove: stepToRemove]]

上のコードは正しくフォーマットされています。しかし、醜いコード
です。私たちは、フォーマッティング・ルールを破って、余分なリタ
ーンやタブを追加して、醜さを取り除こうとするかもしれません。

                removeStep
                    | stepToRemove |
                    stepToRemove := self list selection.
                    stepToRemove isNil ifFalse:
                        [stepToRemove isExecutable ifTrue:
                            [self list remove: stepToRemove.
                            steps remove: stepToRemove]]

見てみましょう。まだ醜いコードです。よりよい解決は、リファクタす
ることです。例えば次のように。

                removeStep
                    self removeStep: self list selection

                removeStep: aStep
                    aStep isNil ifTrue: [^self].
                    aStep isExecutable ifFalse: [^self].
                    self list remove: aStep.
                    steps remove: aStep

メソッドがよく見えるようにするために、フォーマッティングのルール
を破りたい気持ちになった時には、ほとんど全ての場合で、リファク
タリングを行って、よいコードを得ます。やってみましょう。

---
オリジナル http://www.xprogramming.com/
Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)



--
矢崎 博英 <firo@....jp>