インデント数や改行のやり方について、自分の好みを書きます。
言語はJava想定ですが、別言語でも基本的な好みは同じです（IDEは当然使うものとします）。
はじめに
好みとは言いますが、基本的に「合理的と感じるか感じないか」が根拠です（あ、この言い回しオタクっぽい）。
そもそもの話
ぶっちゃけどのフォーマットでも利点と欠点は有ると思います。
特に最近はエディタの整形機能やネスト量の表示機能が優秀なので、「コードを作成する/エディタ上で読む」という部分に着目すれば、どのやり方もそう大きくは変わらないと思います。
インデント数
インデント設定というと、基本的に以下3通りに分けられると思います。
- 2スペース
- 4スペース
- Tab
個人的にはこの内で2スペースインデントが好きです。
2スペースインデントの利点は話し尽くされていると思いますが、単純なコードの読みやすさという観点からはズレた部分で語っていきます。
4スペース対2スペース
2スペースインデントを推す理由は、エディタ外での読みやすさが変わるからです。
例えばSlackに投稿する場合やブログやQiitaに記事を作る場合、読みやすい横幅はエディタよりも小さくなるため、4スペースインデントではしばしば不都合があります。
この傾向は、スマホなどの環境でコードを読む時により顕著です。
コード部分が横にスクロールしてくれるならまだいい方で、改行折り返しされてしまうと構造が崩れてもう読めません。
エンジニアにアウトプットが推奨される昨今、エディタ外での読みやすさを考えてコーディングするというのはトレンドになって欲しいなーと思います（とか言いつつ4スペースインデントで記事を量産してるけど）。
Tabインデント
私的にこのような話をしていたところ、「Tabインデントにして幅は個人で設定できるようにすればいいんじゃないか」という意見を頂きましたが、個人的にTabインデントは好きじゃないです。
理由は以下の3点です。
- 環境によって表示が異なる場合がある
- 環境ごとに表示設定しなければならず面倒（最悪設定できない場合もありうる）
- Tabと半角スペースが混じっても見分けられないため、表示が崩れる場合がある
半角スペースをそのまま打つインデントであれば、どんな環境でもある程度読める状態でコードが出ますが、Tabの場合は8文字分のスペースで表示されてしまう場合が有るなど、状況によって設定の修正が必要となります。場合によってはその設定が用意されていないかもしれません。
また、半角スペースとTabとが混じった場合も面倒です。混じっておかしくなる位なら、Tabは入力禁止としたほうが合理的だと思います。
ということで、Tabインデントは好きじゃないです。
改行の方式
大きく、ブロックの改行と引数の改行について書きます。
ブロックの改行
大体以下2種類に分けられると思いますが、個人的に前者のほうが好きです。
if (hoge) {
}
if (hoge)
{
}
理由
以下2点から、現状の環境では「改行量が多い=良くないこと」だと感じるからです。
- IDEの補助線等の機能から見やすさに殆ど差がない
- 1画面により多くの情報を表示できたほうがコード間を行き来する回数が減る分可読性が上がる（コード間の物理的距離が離れると可読性が下がる）
特に後者は縦に長すぎる関数の可読性が低い辺りから明らかじゃないかと思います。
引数の改行の方式
引数の改行は、以下2つの方式を知っています。
前者はJavaDocの表示などでよく見るパターンですが、個人的には後者のほうが好きです。
void func(int a, int b) { }
void func( int a, int b ) { }
理由
前者では以下3点辛さが有ることが理由です。
- 引数以前に最長で「インデント + 修飾子 + 戻り値の型 + 関数名」となるため、これらが物凄く長くなった場合に後続の引数を書きにくい
- メソッド引数を閉じる部分は最長で「アノテーション + 引数の型 + 引数名 + throws句」となるため、メソッド引数開始部分までが長くなると書きにくい
- （エディタ外で書く時）等幅じゃないフォントだと調整が難しい
極端な例では以下のようになります。
protected static final TypeOfHogerara MethodNameOfHugaGaga(ArgumentTypeOfFooFoo argumentTypeOfFooFoo, @AnnotationOfPiyoPiyo(value = "ValueValue") ArgumentTypeOfBarBar argumentTypeOfBarBar) throws ExceptionTypeOfBuzzBuzz {
protected static final TypeOfHogerara MethodNameOfHugaGaga( ArgumentTypeOfFooFoo argumentTypeOfFooFoo, @AnnotationOfPiyoPiyo(value = "ValueValue") ArgumentTypeOfBarBar argumentTypeOfBarBar ) throws ExceptionTypeOfBuzzBuzz {
結論
ここまで長々書いてきましたが、最終的にはチーム内で定めた自動整形ルールに任せるのが一番だと思います。
インデントやらは本質的な作業ではないので、整形はプログラムに任せて人間はプログラミングに集中すべきでしょう。
ただ、最近のモダンな言語はどんどんコード中の情報密度が上がっていると感じるので、その延長線上で「大量の改行が入るだとか、大量のインデントが入るスタイルというのは環境に適していないんじゃないかなあ」とは感じています。
C言語の登場以来50年弱が経過した今、慣習で残っているからと言ってそのフォーマットが可読性に対して合理的かというのはちょっと疑ってかかるべきなんじゃないかなあ、とも。
まとまってませんがこの辺りで終わります。
