中括弧が属する場所

in Vlog

(jp) =

このブログ投稿は、Kevlin Heney によるこの素晴らしい講演に基づいています。

ブログ投稿全体を中括弧に捧げるのはやり過ぎに思えるかもしれませんが、それらについて考える価値はあると思います。 中括弧が 1 つあるだけでなく、これらすべてに大きなメッセージがあるためです。 コードをどのように読み書きするかを考えると、そのコードの品質が向上するだけでなく、自分自身や他の人がコードを扱う際の安心感も高まります。 それはあなたの仕事の流暢さを改善し、あなたの心を解放して本当に重要なことについて考えることができます. たとえば、「アプリケーション ロジック」などです。

以前の認知負荷に関するブログ投稿で、ビジュアル コードの改善について書きました。 今日は、私たちのコードベースで小さな、しかし非常に重要な文字である中括弧に焦点を当てたいと思います。 より具体的には、閉じ中括弧についてはほとんど議論されていないため、開始中括弧のみを見ていきます。

コードサンプルを見てみましょう。

public function __construct(string $publicDirectory, string $configurationFile, PageParser $pageParser, PageRenderer $pageRenderer)

スティッチャーのレンダリング タスクのコンストラクター。 2 つの構成引数と 2 つのオブジェクトが必要です。 画面の幅によっては、このコードが IDE に完全に表示される場合があります。 このウェブサイトでは、そうではありません。

では、このコードの何が問題なのですか? まず第一に、おそらくスクロールして読む必要があります。 それは悪いことです。 スクロールには、開発者が実行する追加のアクションが必要です。 このメソッドの引数に関する情報を意識的に検索する必要があります。 その時間は、アプリケーション コードに集中できなくなります。

第二に、あなたが Web 開発者であれば、人々が読むのではなくスキャンすることをおそらく知っているでしょう。 これは、最大の注目領域が左側に傾いている Web サイトに特に当てはまります。 同じことがコードの読み取りにも当てはまります。 重要な情報を右に置くと見つけにくくなりますし、左に置くほど重要性が伝わりません。

引数リストの場合、すべての引数が等しく重要です。 しかし、上記の例では、多くの有益な情報がその右側のダークサイドに押しやられています。

では、有用な情報をより左側に引き出すにはどうすればよいでしょうか。

public function __construct(string $publicDirectory, 
                            string $configurationFile, 
                            PageParser $pageParser, 
                            PageRenderer $pageRenderer)

これはあなたが最初に考えることかもしれません。 しかし、実際にはスケーリングしません。 メソッド名をリファクタリングするとすぐに、アライメントが崩れます。 これを通常のコンストラクターではなく静的コンストラクターにしたいとします。

public static function create(string $publicDirectory, 
                            string $configurationFile, 
                            PageParser $pageParser, 
                            PageRenderer $pageRenderer) {

アライメントが壊れているのがわかりますか？ このアプローチのもう 1 つの問題は、物事がまだかなり右に押し出されていることです。 別のアプローチを見てみましょう。

public function __construct(
    string $publicDirectory, string $configurationFile, 
    PageParser $pageParser, PageRenderer $pageRenderer)

ここでの利点は、リファクタリングのアライメントの問題が解決されることです。 しかし、1 行にいくつの引数を入れる必要があるかをどのように決定しますか? これについてスタイリングのガイドラインを作成していただけますか？ それらをどのように実施しますか？ この例には 4 つの引数がありますが、3 つまたは 5 つある場合はどうなるでしょうか。

一貫性が重要です。 これについて一貫したルールがあれば、もう考える必要はありません。 前にも言ったように、これについて考える必要がなければ、頭の中にもっと重要なことを考える余地があります。

それでは、その一貫性を探し続けましょう。

public function __construct(
    string $publicDirectory, 
    string $configurationFile, 
    PageParser $pageParser, 
    PageRenderer $pageRenderer) 
    $this->publicDirectory = rtrim($publicDirectory, "https://stitcher.io/");
    $this->configurationFile = $configurationFile;
    $this->pageParser = $pageParser;
    $this->pageRenderer = $pageRenderer;

各引数に独自の行を与えることで、上記の問題を解決します。 しかし、この例にはまだ 1 つの問題があります。それは、引数リストとメソッド本体を区別するのが難しいことです。

Kevlin Heney は、この問題をシンプルかつ巧妙な方法で視覚化しています。 このコードのすべての文字を X に置き換えましょう。

XXXXXX XXXXXXXX __XXXXXXXXX(
    XXXXXX XXXXXXXXXXXXXXXX, 
    XXXXXX XXXXXXXXXXXXXXXXXX, 
    XXXXXXXXXX XXXXXXXXXXX, 
    XXXXXXXXXXXX XXXXXXXXXXXXX) 
    XXXXXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXXXXXXXXXXXXXXXXX;
    XXXXXXXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXXXXXXX;
    XXXXXXXXXXXXXXXXX = XXXXXXXXXXX;
    XXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXX;

引数リストがどこで終わり、メソッド本体がどこで始まるかを見つけるのがどれほど困難になったかがわかりますか?

「終わりを示す中括弧が右側にまだある」と言うかもしれません。 それは私たちが避けたいことです！ 視覚的に重要な情報を 左. どうすれば解決できますか？ ケブリン・ヘニーはそれを非常にうまく言い表しています。

結局のところ、中括弧を配置する場所が 1 つあります – Kevlin Heney

XXXXXX XXXXXXXX __XXXXXXXXX(
    XXXXXX XXXXXXXXXXXXXXXX, 
    XXXXXX XXXXXXXXXXXXXXXXXX, 
    XXXXXXXXXX XXXXXXXXXXX, 
    XXXXXXXXXXXX XXXXXXXXXXXXX
) 
    XXXXXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXXXXXXXXXXXXXXXXX;
    XXXXXXXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXXXXXXX;
    XXXXXXXXXXXXXXXXX = XXXXXXXXXXX;
    XXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXX;

そのため、その中かっこを新しい行に置くのが理にかなっています。 最終結果は次のとおりです。

public function __construct(
    string $publicDirectory, 
    string $configurationFile, 
    PageParser $pageParser, 
    PageRenderer $pageRenderer
) 
    $this->publicDirectory = rtrim($publicDirectory, "https://stitcher.io/");
    $this->configurationFile = $configurationFile;
    $this->pageParser = $pageParser;
    $this->pageRenderer = $pageRenderer;

さて、コードを構造化するこの方法が気に入らないかもしれません。 ファイルに不要な長さが追加されると思うかもしれません。 しかし、次の事実を見てください。

  • 重要な情報は、ほとんどのフォーカスがある画面の左側に表示されます。
  • この方法は一貫しているため、読むときに考える必要がありません。 これにより、人間の「記憶空間」の一部が解放されます。認知負荷が軽減されます。 これにより、重要なこと、つまり実際のアプリケーション ロジックに集中することができます。
  • ファイルが「絶対に必要な長さよりも長い」ために死亡した人はいません。 しかし、特にそのコードが読みにくい場合は、他の人が書いたものを読まなければならないため、レガシーコードベースで作業することに非常に不満を感じます。
  • ファイルの長さが本当に気になる場合は、コードを折りたたむことでその問題を解決できます。

私はコーディング時にこのルールを持つのが好きです。 「こうするべきか、ああするべきか」という議論は頭の中で一度もありません。 この一貫性は、自分のコードを書いたり読んだりするのに役立ち、他の開発者にも利益をもたらします。

# 小さな関数は?

関数にパラメーターが 1 つしかない場合、複数の行に分割する必要がありますか? 個人的にはそうは思いません。 上記の規則を厳密に適用する場合、中括弧を同じ行に配置できます。

ただし、引数リストとメソッド本体の間のほぼ空の行に慣れた今、この視覚的な仕切りを小さな関数にも使用するのは良い考えのように思えます。

XXXXXX XXXXXXXX __XXXXXXXXX(XXXXXX XXXXXXXXXXXXXXXX) 

    XXXXXXXXXXXXXXXXXXXXXX = XXXXXXXXXXXXXXXX;

ここで、その閉じ括弧の配置について議論を始めることができますが、それは別の機会にブログ投稿します.

# そして制御構造?

についての質問 if、 for、 while もちろん、他の問題にも対処する必要があります。 私の意見では、答えは簡単です。同じルールをそれらに適用できます。

オペランドが右に押し込まれすぎていて、それを分割する必要があると感じた場合は、次のようにします。

if (
    $firstCondition === $secondCondition
    || $thirdOperand === 1
    || $fourthOperand
)

最後に、これは大胆な考えです。ちなみに、標準に従うことも良いことなので、私自身はこれを行いません。同じルールを短い制御構造に適用することは理にかなっているかもしれません。 結局のところ、一貫性ですね。

foreach ($things as $thing)

まだ納得していない場合は、その理由をぜひお聞かせください。 あなたは私に手を差し伸べることができます ツイッター または電子メールで。 これについてあなたとさらに話し合うことを楽しみにしています！

きれいなコードを読むためにもっと探しているなら。 このブログをもう少し閲覧してみてください。 これが最良の出発点です。

//platform.twitter.com/widgets.js

関連記事

前の投稿
2022年はHalo Infiniteにとってラフでしたが、MCCではありませんでした
次の投稿
ミシシッピ川で蒸気船が人気なのはなぜですか?

関連記事