最近、いくつかの異なるチームで、彼らのコーディング規約におけるスペースの使い方が大きく異なっていることに気づきました。これには好奇心をそそられました。なぜなら、コードフォーマットでのスペースの使用については、誰もが認める最良の習慣があるはずだと常に感じていたからです。しかし、実際の開発では、そのような統一は現れていないようです。
現状
まず、ほとんどのJava IDEでのJavaコードのスタイル習慣を見てみましょう。
次に例を示します:
public class Example {
public static void main(String[] args) {
int answer = 2 + 4 * 6;
for (int i = 0; i < 5; i++) {
doSomething();
}
System.out.println("The answer is " + answer);
}
private static void doSomething() {
// something
}
}
注意してください。これはJavaプログラマーや、C言語に似た他の言語において最も一般的なスタイルです。
括弧の内側の両側にはスペースを入れません。括弧の前にforやwhileなどのキーワードがある場合にのみ、それらの間にスペースが現れますが、メソッド名とその後の括弧の間にはスペースがありません。ただし、左中括弧の前には常にスペースがあります(この左中括弧は通常、行の最後に置かれます)。数学演算子は常にスペースで囲まれます。セミコロンの前にはスペースを入れません。
頻繁にコードを読む人なら、これは非常に自然な取り決めだと思うかもしれません。しかし、プログラマーでなければ、これらのルールはあまりに恣意的で、多くの不統一や特例、議論の余地があると感じるかもしれません。
あなたのコードにもっと余白を残してください
現在の開発プロジェクトでは、会社に2つの主要な開発チームがあります。1つはLoad Test Products(LTP)チーム、もう1つはFunctional Test Products(FTP)チームです。両チームではいくつかのコーディングスタイルの習慣に従っており、その中でもスペースの使い方は特に寛大です。例えば、以下のコード断片のようになります:
public class Example
{
public static void main( String[] args )
{
int answer = 2 + 4 * 6;
for( int i = 0; i < 5; i++ )
{
doSomething();
}
System.out.println( "The answer is " + answer );
}
private static void doSomething()
{
// something
}
}
このスタイルは、コードの密度がより低く、より統一性があるように見えます(例えば、左括弧の前にはスペースがなく、すべての括弧、中括弧、角括弧の左右の内側にスペースがあります)!私はこれが以前のスタイルより良いとか悪いとか言っているのではありません…ただ、単語を区別しやすくなるだけです。代償として、1つの画面に表示できるコードが少なくなります。
それぞれのコーディングスタイルには長所と短所がありますが、私が驚いたのは、FTP開発チームが最終的に前述の最も一般的なコーディングスタイルに切り替えることを決定したことです。彼らはこの移行には価値があると考えており、実際に議論も行っていたので、彼らにとってこの移行が重要だったのだと思います。彼らの判断の根拠は、これがあれより優れているからではなく…私は、これは主に誰がこのスタイルに慣れているかという点に着目したものだと思います。なぜなら、私たちの製品のほとんどはオープンソースであり、コミュニティ内のプログラマーがコードを寄贈しやすくすることが重要な理由だからです。
私のチーム、LTPチームでは、私たちは今でも自分たちのスタイルを貫いており、変更するつもりはありません。少なくとも私にとっては、これは技術的な考慮に基づく決定です:もし別のコーディングスタイルが何の利点も示さないのであれば(私たちのこのプロジェクトはオープンソースへの寄贈の必要性がほとんどありません)、なぜ別のスタイルに切り替える必要があるのでしょうか?
ルールは統一する必要がある
私はこれまでずっとオープンソースプロジェクトにコードを寄贈してきました。例えばCeylonプログラミング言語です。非常に驚かされたのは、彼らがまったくコーディングスタイルを守っていないことです。好きなスタイルでコードを書くことができます。
もしかすると、企業内の大量のコーディング規約に怖気づいたプログラマーもいるかもしれませんが、私の考えでは、コーディング規約が一つもなければ、プロジェクトのコードはフォーマットが混沌とする可能性が高いです。各コード提供者は、コミットするコードに自分特有のコードスタイルを持ち込みます。これは不思議なことではありません。その結果、すべてのコードがバラバラになり、以下の数行のコードだけでも多種多様なスタイルを見ることができます:
while (exists cell = iter) {
if (exists elem = cell.element,
elem==element) {
last = cell;
}
iter = cell.rest;
}
}
if (exists cell=last){
cell.element=replacement;
return true;
}
assert (0<=index<length);
私が主に提起したい問題は次の通りです:コーディングスタイルは本当に重要な開発規律なのでしょうか?それはプログラマーがソフトウェアを開発する効率にどの程度影響するのでしょうか?
この問題は、もう一つの似たような問題につながっていると信じています:コードのフォーマットはコードの可読性に影響するのでしょうか?
コードのフォーマットはコードの可読性に影響する
私は、この問題は非常に答えやすいと思います!もちろん影響します。以下の2つのコード(Ceylonプロジェクトから選んだもの)を目で1行ずつスキャンしてみれば、どちらが読みやすいか容易に感じ取れるでしょう。 – CeylonCreate)?
function validModuleNameChar(Character c)=>c.letter||c.digit||c in ['_','.' ];
if (!trimmedName.empty,
validModuleNameFirstChar(trimmedName.first else 'X'),
trimmedName.every(validModuleNameChar),
!(trimmedName.split('.'.equals,true,false)).containsAny(ceylonKeywords.chain {""})) {
return trimmedName;
}
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
validModuleNameFirstChar ( trimmedName.first else 'X' ),
trimmedName.every ( validModuleNameChar ),
! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
return trimmedName;
}
それらの違いは小さいかもしれませんが、一日中大量のコードを読むのに多くの時間を費やすなら、その違いは大きくなります。
普通の文章作成から学んだ教訓
コードの可読性と言えば、私たちは人間が普通に文字を読む能力に目を向けるべきかもしれません。この能力は数千年にわたって発達してきたので、より良い解決策がまとめられているはずではないでしょうか!?
「普通の」英語では、スペースについての慣習的な使い方を見て取ることができますが、作家たちが括弧の周囲にスペースを使うべきかどうかを議論しているのを見ることはありません!では、コードが「普通の」英語のように書かれたら、どうなるでしょうか?
上記のシンプルな例に戻りましょう:
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
validModuleNameFirstChar ( trimmedName.first else 'X' ),
trimmedName.every ( validModuleNameChar ),
! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
return trimmedName;
}
コード内の大部分は普通の英語の文と同じです。括弧を使って特定の単語を「グループ化」します。単語と記号の間にスペースを使います——ここで、通常のコーディング習慣とは異なる点に気づきます:メソッドを呼び出すとき、メソッド名とその後の括弧の間にはスペースがなく、オブジェクトのドット演算子の後にも空白を残しません。
これらの場所にスペースがない理由は理解できます。コード内のこれらの括弧やドットは「所有」関係や関連関係を表しているからです。しかし、本当にこのわずかなスペースを詰めてその関係を表す必要があるのでしょうか?上記の例のコードを見ると、とても明確に感じられませんか?
もう一つ、普通の英語には存在しないものは、ネストされた表現です…つまり、普通の英文法には現れない状況があるわけです。しかし、これは大きな問題ではありません。ただ一つの一般的なルールを覚えておけばいいのです:記号の両側にスペースを入れること。
上のコードが少し変だと感じるでしょう?率直に言うと、少し違和感がありますが、それは私がまだ慣れていないだけだと思います。
まだ慣れてはいませんが、これらのコードは読んで理解するのがより容易だと確信しています。
はっきり言えるのは、すべてのコードがこのような習慣に従っていれば、私たちプログラマーがコードを読むプロセスはずっと楽になるでしょう。
終わりに
事前に定義されたコーディング規約に従うことがプログラミングを困難にすると思うプログラマーがいないことを願っています!
まず、すべてのIDEはコードのフォーマットを自動的に調整するように設定できます。コードを書くときは乱雑に書いてもかまいませんが、最後にIDEのショートカットキーを使ってコードを整理することを忘れず、それからコードをコミットしてください。同様に、文字を書くフォーマットが厳しすぎて創作を制限すると思う作家は、おそらくいないでしょう。
幸いなことに、現在のすべてのコーディングスタイルや規約におけるスペースの使用習慣には大きな問題がないことが分かります。しかし、スペースをもう少し多く使うことで、コードは間違いなくより明確で読みやすくなります。
外国語の原文:Give your code some space!
情報源:外刊IT评论