プログラミングにおいて、ソースコードの綺麗さと保守性・可読性を保つための表記手段として、「適切な字下げ」と「適切なスペーシング」があるわけ。
まず、字下げ。主にブロックを表すのに使う。
例。
#include <stdio.h>
int main(void) {
int n;
scanf("%d", &n);
if (n == 0) {
printf("nはゼロです。\n");
} else {
printf("nは%dです。\n", n);
}
return 0;
}ブロックを表すというのはどういうことか。1段目付近を見ていけば分かるだろう。
・まず、#にぶつかる。 とくに1行で終わるので、なにもない。
・次にint～にぶつかる。行末に始まり括弧がある。
・この次の行から一段下がっている。ここからが１ブロックだ。
・対応する終わり括弧を探すのは簡単。だって1段目だけを追っていけばいいから。
こんなふうに、対応が取れるのです。わかるかな？
ところで、この字下げスタイルはK&Rのものに似ているけれどちょっと違う。
K&Rでは、関数の始まりは
int main(void)
{のように表記する。中括弧を「落とす」。これは歴史的な経緯が関係あるけれど、その辺は割愛。
ではなぜ、これを使わないのか。理由は一つ。「行数削減」だ。
両方の括弧を落としてしまうと、意味のない行が2行できる。対して、始まりを乗せると、今度はこれが1行になる。たかが1行だけれど、それでも50%だ。
また、字下げは一つの疑問を生むことになる。
「長く書く部分なのに、字下げされているとタブの入力が面倒じゃないか」
そのとおりですね。手入力なんてやってられません。
いや、だからといって取り除いてしまうのは良くない。だから、エディタに任せるのだ。最近のエディタは偉いから、Cぐらいなら難なくスマートインデントしてくれるよ。
それと、字下げ幅は趣味がある。2とか4とか8が主流だけれど、中には奇数幅の人だって居るかもしれない。
だから、これもエディタに任せちゃう。tab文字を使うんだ。大体のエディタはtab文字幅を調節できるから、読む人が任意に設定すればいい。
字下げ幅に悩む箇所は、いくつかある。
1. 関数の引数が多く、2行以上になってしまった時、関数本体は何処に書いたらいいのか。
そのまま一段下げにすれば、普段と同じ高さ。でも、すぐ上の引数リストと同じ高さになってしまう。自分は、引数リストの閉じ括弧と本体の始まり括弧を次の行に持ってきてしまう。
2. プリプロセッサ命令。
これらは処理レベルが違う。だから、そういうことを明示するために、あえて字下げなしで書くことが多い。
3. switch文。
caseラベルと実行文は、一段ずらして書くのはおきまりみたいだけれど、caseラベルをどの階層に置くかは好みとエディタ次第かもしれない。
switch（）がある階層と同じにするのも悪くない。一段下げて、結果実行文が二段下がるのも悪くない。
全然スペースが余ってるし、スペーシングの話もしようか。
適切なスペーシングが必要な理由は、言語仕様にも書いてある。以下の一文があったとしよう。
n=x+++++y;
これは、コンパイルエラー。なぜなら：
・まずトークンが区切られる。左寄せで区切るので、「n = x ++ ++ + y ;」となる。
・演算子の優先順位に従って、「x++」が処理される。
・つぎに、その隣の「++」が処理対象になるが、被演算数は「x++」の演算結果、つまりは定数なのでインクリメントできない。よってコンパイルエラー。
さて、ここで以下のようにスペーシングする。
n = x++ + ++y;
これならコンパイルエラーにならない。説明がめんどくさいから、言語仕様を読んで欲しい。
さて、だいじさはわかっただろうか。ここでは一例を紹介する。
関数定義の時、関数名と引数括弧はくっつける。関数本体の中括弧は離す。
カンマの前はつける、後は離す。
制御構文と条件括弧は離す。関数呼び出しでないことを明示するため。
括弧の外側は離す、内側はつける。ただし、キャストの括弧はつける。
間接参照演算子は、変数の前につける。
その他単項演算子は基本的につける。
二項以上の演算子は、演算子と対象を離す。
自分はスペースの量はそこそこだと思うので、好きな人はとにかく離すかもしれない。
あとC++のテンプレートクラスにグローバルスコープ演算子入れた時に、三つ組みで詰んだ人とか。
スペースが少ないコードは、横に詰まって見える。汚いからやめてほしい。
ちなみに、コードをコピペすると、スペーシングでばれてしまうよ。一度本で、一部分だけスペーシングが違うのを見つけてしまって、ああ、コピペしたんだなってすぐ分かったから。
まとめ。綺麗に書くって、すばらしい。
