堅牢なコーディングルールを策定する方法(1) - 都元ダイスケ IT-PRESS

「ある処理をするコードを書く」というのは「ある出来事を文章に表現する」のと似ていると思っている。 まず表現に使う言語は様々であり、使用人口の大小はあれど、基本的に優劣はない。言語が同じだったとしても、十人十色の表現をし、全く同じ出来事を表現したものであっても、複数人が全く同じ文章を作る可能性は限りなく小さい。同じ人が表現するんであっても、今と昔で「全く同じ文章」を書くとは限らない。むしろ微妙に差異があるのが普通だ。 そんな「コーディング」に一貫性を持たせるのがコーディングルールだ。インデントはスペース4つだとか、braceの位置はどうだとか。複数人で小説を執筆する*1場合は、「ですます調に統一しよう」とか色々な取り決めをすると思う。このあたりの一貫性がないと、非常に読みにくい小説が出来上がるだろう。 とまぁ、ルールってのは、複数人間の意識合わせのために*2存在する。例えば法律もそうだ。そし

[rna]

ルールのルール。明確で独立で判断コストが小さいルールにするべき、という話。/例題はFooの抽象レベルに合った例外を(必要なら定義して)投げるべきかな? 場合によってはthrows NFEしてdoc comment書いて済ますかも。

[rryu]

バグとはプログラムが望んだ通りに動いていないという状態なのでその望みが分からないと何とも。例外限定でルールで明示するのなら、投げる例外はthrowsですべて明示するか、投げられる例外は全てキャッチするとか?

[fuktommy]

明文化したルールというよりも、口伝・職人芸的な、"福冨流" みたいなものとして伝わるんじゃないか、という気もする昨今。

[hysa]

１．Fooのバグ派。

[totttte]

＞結論を出すプロセスがライトウェイトである 複数人が集まって議論しないと結論が出ない、とかはヘビーウェイトですね。

[hush_puppy]

変な処理するならコメントに意図を書いとけ派

[terazzo]

たまにDbC的なもの導入したくなる(口だけ)

[kodaif]

"判断がつかない。まぁ、その人は気持ちよかったんだろうなぁ、いや、もしかしたら気持ち悪いと思いつつも書き進めてしまったのか？ ……エンジニアの時間は貴重である。こんなことに頭を悩ませるなんて勿体無い。"

[FunnyBunnyDizzy]

1.Fooのバグ説 派。