POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook
Terence Eden

本記事は、原著者の許諾のもとに翻訳・掲載しております。

先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。

議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。

垂直方向にそろえるインデントをとるとは?

簡単な例を挙げてみます。

int robert_age = 32;
int annalouise_age = 25;
int bob_age = 250;
int dorothy_age = 56;

次のようにすると、もっと読みやすくなります。

int robert_age     = 32;
int annalouise_age = 25;
int bob_age        = 250;
int dorothy_age    = 56;

ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。

この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガイドと考えるのか私なりに説明してみようと思います。

理解しやすさ

プログラミング作業の90%は問題の解決に費やされ、 残りの90%は その解決方法の理解に費やされます。

コードを読むことは散文を読むこととさほど違いはありません。どちらの場合も書き手に期待するのは、選んだ言語を主題と無関係に使って冗長にせずに、論旨を明確に説明し、ごく一般的な文法スタイルを順守することです。

実際に、Kernelのコーディングスタイルは、このことを重視しています。変数の名付け方は、コーディングで何を実現するのかと同じくらい重要です。

次のコードについて考えてみましょう。

var thinG=doIt(thestuff,MORE_sTuff); /* LOL! */

もしコードベースを深く理解していたとしても、さほど読みやすいとは言えないコードですね。

var totalBill = apply_tax(initialBill, taxRate);

名前の付け方やスペースの入れ方、さらにキャピタライゼーションルールをよく考えて適用することで、私たちのコードはかなり読みやすくなりました。つまり、私たちのコードを引き継ぐ人がいたとしても、解読作業にあまり時間をとられることなく、内容の理解に時間をかけられるでしょう。

なぜ等幅フォントを使うのか?

昔からよくある炎上と同じように、等幅フォントとプロポーショナルフォントの間には、どちらも同じくらい情熱的な支持者がいます。

コーディングには プロポーショナル フォント最適 だと言う愚かな人もいるでしょう。しかしそんな野蛮人たちは相手にしないでください。
また、等幅フォントに違和感を与えようとする人もいるでしょう。彼らは プロポーショナル フォント が優れたコードを作ると 純粋 に主張しているからです。しかしそれも、軽薄で哀れな精神です。

結局のところ、読みやすさに行き着きます。どんな表現なら、コードを最も理解しやすいでしょうか? それは、IDEの文字のカラー定義です。つまりあなたは一目で「foo」が関数なのか、定数なのか、変数なのか、もしくはコメントなのか分かります。コードの中でそのブロックが何なのかをすぐに理解できることは、どんなことでも素晴らしいことなのです!

スプレッドシートの人気が高いのはそれが理由です。列によってそろっているので、読みやすくなります。上から下へ列に沿って素早く目視で見ても、もし他と著しく異なる行があれば、気づくことができるでしょう。

私たちにはツールがない

興味深いことに、Hacker Newsでの議論で私が直面した大きな批判は、垂直方向にそろえるインデントが有用かどうかではありませんでした。私たちが普段使っているツールがいかに貧弱かについてだったのです。

この書式は、コードの読みやすさやコード比較のユーザビリティを台無しにします。ある1つの定数が変化することで生じる大きなバグを、すぐに解消する必要があるとしましょう。水平方向にそろえるインデントをとっている場合、diffをとると変化した行番号全てを含んでしまい、致命的な変更が見えなくなってしまうでしょう。スペースや文字ベースの違いを無視する回避策はありますが、個人的には、そこまでする必要はないと思います。
Andreas van Cranenburgh

そして…

例えば50行のプログラムを書いていると仮定します。最大文字幅を持つ値に合わせて全ての値のインデントをとるとしましょう。すると、新たにプログラムに挿入された値が最大文字幅であった場合に、その値がとるインデントに合わせて既に書き終えた50行を更新しなければならなりません。私自身、まさにこのような状況に陥ったことがあり、その時、コードのインデントをそろえるべきでないということが分かりました。
scrollaway

上記に挙げた意見は、ある状況においては正当だと言えますが、言いかえると、より良いツールが必要だということを示しているのではないでしょうか。

今、私は、 Elastic Tabstops という、コードブロックのインデントを自動的にとるアイデアを思い出しました。

By Nick Gravgaard

Nick Gravgaard作

ツールでは簡単にこの方法を適用することができます。このような退屈で反復的な仕事をするためにコンピュータが存在しているのであり、コードが更に読みやすくなることを考えれば、そこでCPUサイクルをどんなに”浪費”したとしても安いものでしょう。

垂直方向にインデントをそろえて、コードを読みやすくすることについては Linux Kernel を参照すると 多数 を見つけることができます。

垂直方向にそろえるインデントは、あらゆる状況で有効なわけではありませんが、データの評価を迅速に行う上での可読性は、そろえない場合からすると比較にならないほど高くなります。

コーディングは、自分自身の考えを表現する創造的な方法です。表現したアイデアを難しく見せてしまうようなツールであるのなら、インデントではなく、ツール自体を改善すべきでしょう。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。