制御構造のコーディング規約

色々あるみたいだが、適当に思ったことを。

if ( hoge ) {
    hogehoge;
}
else {
    fuga
}

上記のような書き方は、なんだかクシャッとしていて見難くて、受け入れづらかった。
なので、GNUのコーディング規約でもあり、Linux・Unixのパッケージのソースなどでよく用いられていて、大学でもC言語な人達が好んで使用していた以下のようなコーディング法を個人的に気に入って使っている。

if ( hoge )
{
    hogehoge;
}
else
{
    fuga
}



大学など研究機関で、毎日コーディングをしている人達のコードを見てると、圧倒的に後者の方が多かったが、会社ではそれぞれの言語におけるきちんとしたコーディング規約守るべきだというような考えからか、前者の方が多いのかな??
後者を好む人たちはほぼ、前者の「if」に続けて「{」を記述することが、非常に見づらいと言っていたように思う。
もちろんそういう人たちは、言語が変わっても、制御構造の書き方を変えていなかった。

参考までに、プロコン受賞者の人も、1位と3位は後者のコーディング法、2位の人は前者のようだ。

会社の師匠は、前者派のようで、後者は微妙に感じるようだ。

しかし、大学でも、この前者・後者の差は好みの問題と考える人が大多数であり、僕もその一人で、この部分の可読性の影響は、全体のコードの可読性に対して、非常に小さいと考えられる。
というのは、それ以前に可読性が低いものは別のところに問題があり、この制御構造のコーディングの差が可読性に大きく影響することは考えられないからだ。
さらには、人それぞれこの部分の可読性の高さの捉え方が別れるところなのであれば、それこそ好みで決めてよい部分だと考えられるため、ここはゆずれないところである。

また、いくら他人への可読性といっても、自分が見るレベルで見難いものは見難い。

そもそも、コーディング規約は、共同で製作する人と決めたらよいもので、個人的な自分のコーディングはある程度自分自身の規約を一貫していて、極端なことをせず、可読性がよければ問題ないように思うのだ。

PHPやPerlなどをGNUのコーディング規約に基づいて書いても、何も可読性で劣るところは無いように思うし、むしろ美しく感じる。
特にGNUの規約では、「ifの行の下に「{」を書きなさい」と書かれているわけではなく、その点は自由のようだが、サンプル等は後者の記述法である。
実際、以下の記述がある。

我々は以下のものを必須とは考えていません. 二つの別々のプログラムが異なるフォーマッティングスタイルを使ってもユーザには何の問題もないからです.

ただし, どんなスタイルを使うにしても, それを一貫して使ってください. 一つのプログラムでスタイルを混ぜて使うと読みにくくなるからです.
既存のプログラムに読者が行った変更を寄与するなら, そのプログラムのスタイルに従ってください.

-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob

`-bl‘ オプションを指定するとブレースは以下のように整形される:

if (x > 0)
{
    x--;
}

`-bl‘ オプションを使う場合には `-bli‘ オプションも使うとよい。このオプションはブレースのインデント付けに使う空白の数を指定する。 `-bli2‘ (デフォルト値)を指定すると、先に示した結果となる。 `-bli0‘ を指定した場合の結果は以下である:

if (x > 0)
{
    x--;
}

これは、つまり規約として縛る部分であると考えていないことの表れではないか。
その上で、GNUは後者の書き方を「個人」として見やすいと考えているようにとれる。
それに対し、「ifの行に「{」を書きなさい」みたいな縛りをいれるコーディング規約の方が、よっぽどおかしいように思う。

なぜなら、上記の例を見比べるた時、「前者の方が見づらい」と感じる人がいる可能性が十分あるからである。

そんな微妙なラインを規約として強制している規約の方が、プログラマー間の連携に気を取られ規約をきつくすることで、よっぽど可読性を無視しているように思う。

とりあえずは、可読性や連携等のバランスを考えた場合、個人で書く場合のこの部分のコーディングは、自由にしてよい部分だと思う。
無理に強制でもないコーディング規約に縛られる必要はなく、誰かと共同で作業を行うならば、任意の規約に沿ってコーディングを行えばよい。

そのかわり、基本的なインデント等、明らかに可読性の劣る記述は避けるべきではある。

ひょっとするとこの差が、「企業の技術者」と「大学の研究者」との差なのかもしれないが。

「制御構造のコーディング規約」への4件のフィードバック

  1. おはようございます。

    見ましたよ。
    で、このソースが前者だからといって、僕の主張は何もかわりません。
    というのは、僕が「企業の技術者」と「大学の研究者」との差と言っているのは、「制御構造部のコーディングに関して、片方に規約縛らず、好みのコーディング法を一貫して用いればよい」としているだろうことだからです。
    BSDは、「共同で作業を行う」上で、前者の記述法を規約としただけのことでしょう。

  2. {を使う言語では、
    使い方がマチマチだと可読性、というよりメソッド名を追いずらい、というのが直感的な意見です。メソッドを追って行く度にメソッド定義あたり({の場所、シグニチャの書き方、メソッド間の改行数、など。)が揃っていないと、スピードがのらない。トラブル対応等でソースを追っかけている時等は、結構イライラしてしまう。

    Javaでは圧倒的に前者の方が多い。
    何となく、『短いコードは、美しくて良いコード』みたいな信仰があるように思う。もちろん{の位置を変えたところで実際の実行ステップ数に差は無いんだけど、なんとなく、短く良いコードのように見えるのかも知れない。

    Javaの人間なのでずっと前者だったけど、
    Rubyを扱うようになり、{の無い言語を多用するようになってちょっと認識は変わったかも知れない。ただ、相変わらず多数に合わせて前者で書く。

    企業では、
    コードは企業の財産で、多数の人間に長期に渡ってメンテされる為、必要以上にコーディングに『個人色』を出すのを警戒されているのかも知れない。

    はし

  3. まさに仰るとおりですね、多人数で開発・保守するようなプログラム内で統一されていないのは話にならないと思っています。

    ただ、そういった共有化という意味がある程度以下の場合では、「{」の位置に関しては、好きにやっても構わない部分のような気もしています。
    (もちろんその状況下でも統一されていることは必要です。)

    完全に統一はできないコードでも、多人数や個人に関わらず、必ず統一すべき部分(インデントの有無)と、そうではない部分があるように思うんです。

    で、当記事の上記の差は後者に当てはまるように、個人的に思ったわけなのです。

コメントは受け付けていません。