「 いいコーディング規約、悪いコーディング規約？」2019年版 140
ストーリー by hylom
新たな言語の登場で変わったことはあるかも 部門より
新たな言語の登場で変わったことはあるかも 部門より
Anonymous Coward曰く、
2008年の記事「いいコーディング規約、悪いコーディング規約？ 」より
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。
可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？
SlashdotJ諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ ほかにも、使える「自分ルール」などもあれば是非。
元々のストーリーからは十余年経過してますが、新たな「いい/悪い」は現れただろうか？
見直してよ・・・ (スコア:4, 興味深い)
②1関数は50行に収めろ
③1ファイルは200行に収めろ
②③で超えさせたい場合は理由を添えて申請しろ
※どんな言語でもこれ適用
Re:見直してよ・・・ (スコア:1)
1はlambda式とかfluent interfaceとかずらずら書く方式を使ってるとキツイね。
まあ適当に改行入れれば回避できる。それで行数が極端に増えるってことはないだろう。
2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
機能を詰め込むとテストしづらくなってバグの温床となる。
Re:見直してよ・・・ (スコア:1)
関数に分けることの最大の目的は、処理に名前を付けること。
例えば、池袋から梅田に行く方法を説明するのに、
JRの○○改札を抜けと20メートルほど先に進み、右に曲がったあと7番ホームへの
階段を上り（中略）新幹線を降りたら、右手に進んで階段を降り、まっすぐ進むと
右手に京都線ホームへの階段がある喉（以下略）
みたいな説明されるより、
1. 山手線で品川まで行く。
2. 品川で東海道新幹線に乗る。
3. 新大阪で京都線に乗り換える。
4. 大阪駅で降りる。
山手線で品川まで行く方法は...
のように説明される方がわかりやすい。一回しか使わないから関数化
する必要ないなんて馬鹿はこのことを理解していない。意味のない
関数名を付ける奴も同様。
Re:見直してよ・・・ (スコア:2)
名前をつける効果より
ローカル変数のスコープを最小限にするためとか
使用する変数を最小限に絞る効果のほうが大きそう。