コーディング標準は役に立つのか 154
ストーリー by headless
標準 部門より
標準 部門より
本家/.「Ask Slashdot: Do Coding Standards Make a Difference?」より
私がこれまで勤めた職場はすべて、「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。しかし、アルゴリズムをレビューせずにスペースの使い方を指摘するような人のがいるせいで、コードレビューのために数百時間を無駄にしてきた。実際のところ、このようなコーディング標準を適用することで生産性が上がることを裏付ける資料や研究があるのだろうか。そうでないとしたら、なぜこれらが必要なのだろう。いまどき、決められたコーディング標準を自動的にツールが適用してくれてもよさそうなものだ。
コーディング標準はツールが自動的に適用してくれます。 (スコア:5, 参考になる)
＞「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。
じゃ、読みましょう。適用しましょう。
前提となるドキュメントを読んでいないようなのに、レビューしてもしょうがありません。
あなたの時間はたしかに無駄になりますが、レビューした場合あなた以外の人が無駄になる可能性があります。
私はEclipse派ですが、自動生成する際のコーディングスタイルを設定できます。
自動生成できない部分に関しては、標準化する際に議論を行い、できるだけ自動化する、または採算が合わないようなら標準化適用外にしてます。
＃標準化って生産性よりも、保守性をあげてるんじゃないの？
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:3, 参考になる)
そういえば、Eclipseのスタイル設定では設定できないスタイルをわざわざ設定してきた意地の悪い発注元があったなあ。ケチをつけてコーディング品質が低いとアヤをかけて、工数単価を事後に値切ったり、仕様変更の追加工数をロハにしようとしたりするひどい発注元でした。
個人的には、識別子の命名規則以外は、レビュー前にindentコマンドで一括整形でいいのではないかと思ってます。
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:2)
その通りですね.
理由なく標準化を守らないのであれば,
それはレビューに対する障害でしょう.
標準化されてないコード箇所があれば,
そこは「怪しいコード」である可能性が高く,
「ここについてフォーカスしてくれ」という指定でもなければ,
レビュー時に最も力を入れるべき箇所です.
また, 標準化を無視するのであれば,
その理由をレビュー時に明確にすればいいだけです.
それは「この標準は生産性を下げる」と問題提起する機会にもなりますし.
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:2)
同じく、EclipseのプラグインでCheckStyleも使ってます。
自動的にチェックしてくれますよね。
Java以外でも使えたような？（言語によるけど）
もし社内独特のコーディング規約が多すぎると
反発おきて守ってくれない人多くなるかもしれませんね。
キャメルが規約となっている中で、アンダースコアばっかり使うソースは読みにくいので、そろえるのはある程度意味ありますね。
システムハンガリアン＋単語の区切りがアンダースコアのソースとかやる気失せる。
目立つノイズが消えると、本当の問題が見えてくる。 (スコア:2)
たとえば、文章の校正をする場合を考えると、文字が汚な過ぎると読み取るのに苦労して、内容のチェックどころではないでしょう。文字のきれい汚いは文章の内容とは関係ないはずですけど。
プログラムの場合も同じであり、にコーディングスタイルがいい加減だったり、変数名・関数名が内容とマッチしていなかったりした場合は、そちらの読解にばかりエネルギーが割かれて、プログラムの内容どころではなくなってしまうのでは無いでしょうか。
Re:目立つノイズが消えると、本当の問題が見えてくる。 (スコア:2, 興味深い)
同意です。学生がもってきた英語の論文の原稿なおすときは、最初の1回の修正は、ほとんど「てにをは」的な修正ばかりです。まずはこれ直してまたもってこいと（または、言いたいことと意味が違ってしまった箇所があったら、別の表現を再提案しろと）。そういう修正だけで真っ赤になって読みにくいというのもありますし、学生の頭を整理させるのにも役立ちます。その後で、論理的な構成について本人の書きたかった事を確認しながら修正する作業に入ります。
Re:目立つノイズが消えると、本当の問題が見えてくる。 (スコア:1)
＞文字が汚な過ぎると読み取るのに苦労して、
その例えば不適切だ。
＃そもそも「文字の綺麗汚い」の問題は、ディスプレイで表示するに白プリンタで
＃打ち出すにしろプログラムでは通常起こらない。
たとえば縦書きか横書きか、
ノートはB罫かA罫かはたまた原稿用紙か、
紙面の大きさはA4かB5か。
或いは電子データにする場合はプレーンテキストなのかMSワードなのか。
そういったことはなるべくなら統一されてる方が良い。
特にたとえば小説/ラノベの新人賞に投稿してくるなら、どの形式で提出しろと定めていてもおかしくはない。
出版を前提にしたプロの場合は、印刷に対応できるフォーマットであることは重要だろう。
また同じ社内で利用する書類なら、同じ報告書のフォーマットが定められているのは普通だろう。
しかし人間の可読性という点においては、それらはほとんど意味のない、どうでもいい話だ。
アンダースコア区切り (オフトピック: -1) (スコア:1)
> 「キャメルケースを使うか、アンダースコアで区切るか」
アンダースコア区切りはキャメルケースに対して「snake case」ですかね
Re:アンダースコア区切り (オフトピック: -1) (スコア:1)
以前、職場のほうぼうに掛け合ってケース呼称を標準化したことがありますが
そのときの結果としてはおおむね無難に
camelCase
PascalCase
snake_case
hyphen-case (あるいはcss-case)
といったところでした。
Re:アンダースコア区切り (オフトピック: -1) (スコア:2, おもしろおかしい)
最後のは職場によって、odango-caseとか、mitarashi-caseとか言ってた。
Re:アンダースコア区切り (オフトピック: -1) (スコア:2, 参考になる)
MISRA C という失敗 (スコア:1)
C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、
関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。
役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。
Re:MISRA C という失敗 (スコア:1, すばらしい洞察)
> 関数の末尾以外の return を禁止する
なぜ禁止なのかわからない人にコードは書かせたくないなあ
Re:MISRA C という失敗 (スコア:1)
>> 関数の末尾以外の return を禁止する
>
>なぜ禁止なのかわからない人にコードは書かせたくないなあ
この人深いネストが連なった山脈みたいなコードを書いてそう。
そんなコードはフルHDモニタが普及した今でも読みたかないよ。
Re:MISRA C という失敗 (スコア:1)
なぜ禁止なのか書いていないから「そのコーディング規約」はダメなんです。
ルールが独り歩きする原因です。
わかりましたか？
Re:MISRA C という失敗 (スコア:1)
禁止の理由はよくわからないんだけど、
関数途中で抜けたいときには Exception を上げればいいということですよね。
そんで呼び出し元で処理する。
Re:MISRA C という失敗 (スコア:2)
私じゅうあ可読性は上がると思います.
それこそ「山脈のようなコード」でなくても.
returnの場合は様々な要因が絡むからアレだけど,
似た例ではif文とif句の違いがあります.
if(a){
x = A;
}else{
x = B;
}
とあるものは,
x = if(a) A else B
あるいは,
x = a?A:B;
の方が大抵の場合は見通しが良いですよね.
文頭から, 「あ, xになんか代入すんだな」っていうことがわかります.
同じことがreturnの場合にも言えるんじゃない?
関数の最後から見て, 何を返すのかを先に知ることで,
見通しは良くなるんじゃないでしょうか?
ここまでの説明で, returnまでの長さが問題じゃないことはわかると思います.
Re:MISRA C という失敗 (スコア:2)
ごめんなさい, 変なタイポが入りました
# ○私 は : ha
# ×私 じゅうあ: jha
Re:MISRA C という失敗 (スコア:1)
関数の入り口と出口がそれぞれ一箇所に限定できるので、処理手順の流れを正順・逆順追っかけるのが楽になるということでしょうか。しかし、いまなら統合環境では return goto break continue といった処理手順に影響するキーワードは強調表示できるので、 それほど問題にならないような気がします。
Re:MISRA C という失敗 (スコア:1)
そう、こういうのはだいたい昔の親切でない言語や開発環境を想定した規約なんだよね。
実際10年ぐらい前には、巨大メソッドの途中にreturn文があって以降が実は使われないゴミ、とかいう酷いプログラムを見かけたこともある。
なので、そういう時代は出口を一か所にしなさいという主張にも、その結果として巨大なif文やらが作られてしまうことが多々あるものの、それでも一定の価値があった。
でも今はJavaなんかだとそもそもそういうのは言語自体でエラーとして検知してくれるし、何より一つ一つのメソッドを小さく作るべき、って思想も浸透してきてる（と思う）ので、この規約は可読性を下げるだけの厄介者でしかない。
Re:MISRA C という失敗 (スコア:2, おもしろおかしい)
元コメがACなら、みんなACで返すしかないじゃない！あなたも、わたしも！
Re:MISRA C という失敗 (スコア:1)
途中で return すると、リソース解放し忘れるミスが増えるから。
コードの見通しの悪さによる保守性悪化と、リソースリークの潜在的危険性を天秤にかけた。
理由としてはそれだけ。
MISRA C の主目的は深刻なバグの入りやすいパターンを避けることだから
大多数にはバカバカしいルールでも、たった一人の間抜けに躓かないための妥協が多くなる。
C にデストラクタがあればこんなルールは生まれないね。
Re:MISRA C という失敗 (スコア:1)
それならそこだけ禁止すればいいだけなのに、なんで全部禁止にしたがるのでしょうね？
その関数がリソース解放しているかどうかぐらい書いている人もレビューする人も分かりますよね。
Re:MISRA C という失敗 (スコア:1)
その関数が一人の人間が見通しの良い行数以内で一度書いて完成、以降の改造も未来永劫ないとは限りませんから。
Re:MISRA C という失敗 (スコア:1)
「そこだけ禁止」言うは易し、行うは難し。
文脈に依存したコーディング規約の適用はすぐに破たんする。
たとえば、リソースを使っていなかったモジュールを後から使うように変えたら、途中 return は全部書き換えるのか。
そもそも管理リソースを減らしたくて一律に適用しているのだから、本末転倒。
Re:MISRA C という失敗 (スコア:1)
残念ながらMISRA C++というC++に対応したとされるものがありまして、
それにも変わらずばかばかしいルールが残ってるんですよね
Re:MISRA C という失敗 (スコア:1)
C言語の規約なんだからそれでいいんじゃない？
C++で強制されたらなんで？になるけど。
で、C++で書いた後「C言語じゃないんで関係ないですよね」が通用するのかどうか調べてみたけどMISRA C++ってのもあるんだな。
http://www.klocwork.com/products/documentation/current-ja/Klocwork_%E3... [klocwork.com]
6-6-5でC言語と変わらず途中returnダメって書いてあってこれ制定した人たちにはがっかり。
例外は禁止してないところからも実際に何を理由に禁止にしたいのかさっぱりわかりません。
Re:MISRA C という失敗 (スコア:1)
最低辺のレベルを確保することでリスクを低下させることを目的としているんでしょうね。
禁止しないことによるメリットも比較検討してほしいところですが、ルールを決める(させる)動機がある奴は
分かってない奴(が対象)なので期待薄。
ツールとか技術レベルの底上げとか状況に応じて改訂していって欲しいけど、「障害事例を
フィードバックしました!」とかいって肥大化するだけだったり。
頭のいい人が言語を作る → 普通の人が頑張って勉強する → 理解できなかった人がルールを作る
こんな感じに思える。
Re:MISRA C という失敗 (スコア:1)
このまま採用というのはMISRA-C の使い方を誤っています。
よくある誤解なのですが、MISRA-C ルールは禁止事項を整備したものではありません。
MISRA-C ルールから逸脱することは想定されており、そのための手続き方法についても
「MISRA-C 2004 C言語利用の高信頼化ガイド」(ISBN4-542-50346-1) の
4.5 で延べられています。
手続きをとらせることで、その逸脱したコードには本で述べられているような
問題点がないことを再確認してもらうことが、本来のMISRA-C の使い方になります。
タブやカッコの使い方ぐらい自動化すればいい (スコア:1)
問題はExcel設計書のコーディング規約だ。
自動化もできないし、折り返し禁止だと推敲効率ガタ落ちになるし、とどめに明文化されていない俺様ルールが多すぎる。
Re:タブやカッコの使い方ぐらい自動化すればいい (スコア:1)
おれはXMLでほぞんしてWinMergeだな
Re:タブやカッコの使い方ぐらい自動化すればいい (スコア:1)
WinMerge(プラグイン併用)と、あとは最近のTortoiseSVNの差分ビューワでも(多少おかしい場合もありますが)見れますよね。
オートシェイプとかはちょっと無理だと思いますが、セル内のテキストは何とかチェックできて便利です。
Re:タブやカッコの使い方ぐらい自動化すればいい (スコア:1)
まあ煽りなんだろうけど・・・Wordでもセル単位（表の場合）や文字単位で背景色が付けられるぞ。
ナニ、やり方がわからないものは認めない！？
こまけーことはいいんだよ。 (スコア:1)
ここまでで誰も具体的な数字データを上げないな。
僕も持っていないからよくわかんないけど。
思うに、自動整形ツールで直せるぐらいの範囲だったら、その規約は意味をなしていないように思える。
ツールで修正してしまえばいい。
例:インデントの幅、if (){ の {の位置とか。
変数名やメソッド名も置換ツールでどうにかなるだろう。
逆にツールで直せない問題こそ、
人間が注意するべきところだろうと思う。
これこそ規約で目標値を定めればいいと思うな。
例:長すぎる関数、でかいループ(whileが1000行あるとか)、でかすぎるクラス(多すぎるメンバ変数)、深すぎる継承
グローバル変数と化したsingleton、テスト不足とか。
by rti.
本家コメントより (スコア:1)
THE reaSON WHy coDiNg standards_exist is thatTheyIncrease THE_REaDABILITY oF YOur cODe.
http://ask.slashdot.org/comments.pl?sid=3333189&cid=42363115 [slashdot.org]
「コーディング標準」？それは「オレが標準」の間違いではないですか？ (スコア:1)
ここのやり取り見てるだけでもコーディング標準は軋轢を生み、それを解決するためのコストが大きすぎると思った
口先では標準大事と言いながらも、本音は自分の好きな書き方を標準にしたいだけでしょ？
Re:インデント (スコア:1)
ここで重要なのはオートインデントができる言語と、できない（或いは困難な）言語があることだと思う。
できる言語なら適当なプログラムに食わせれば済む話だけど、
できない言語でメタ糞なインデントを付けられた場合はそれなりに大変。
しかもそういうコードが同時にスパゲッティでもある時は、軽く死ねる。
その違いを分かってない勉強不足な管理職が、作ることを目的にして規約を作ったりすることが
少なくないから、「管理職と規約イラネ」ってなることが多いんだと思う。
Re:コーディング標準に縛られる必要はないけど (スコア:2)
自分が見るだけなら適当でも問題ないかな、とちょっと思ったが、
数週間経った自分は他人も同然だから、やっぱ考慮しておくべきだな。
Re:ストレスなく読めれば何でも良いよ。 (スコア:2)
defineで関数名置換する所があって、呼び出し先探すのが・・・・・・
さらに、関数ポインタで呼び出しもするので検索しても出なかったり・・・・
Re:ストレスなく読めれば何でも良いよ。 (スコア:2)
# C++でわ、条件コンパイル又はデバグ用な特殊引数付き以外、プリプロセッサマクロは不要且著しく有害。
Re:ストレスなく読めれば何でも良いよ。 (スコア:2)
しかも、前述の関数ポインタでC++の真似事をしているという・・・。
Re:適用の簡単さによるというか (スコア:1)
「Listを返すメソッドはnullではなく空オブジェクトを返す」みたいなのは？
Re:適用の簡単さによるというか (スコア:1)
Re:あったけど (スコア:2)
でも、レビュアー（又は後継者）が、ソースを理解する為に考えようとしない姿勢がいかがかと。
昔の話ですが、
某Ｆ社に派遣で行っていた時にレビューを受けた時、
「確かに正常に動いてるけど、（ソースのロジックが）よく分からないから書き直して」
って言われた時は、キレそうになりました。
「ロジックちゃんと説明したろうが！！頭使えや！！」
って言いかけてギリギリ飲みこんだ記憶が。
＃10年以上前の話だから時効だよね？
Re:あったけど (スコア:1)
＞確かに正常に動いているけど、ロジックに無駄がある。
＞俺が書きなおしたら数十行が数行になった。
逆です（苦笑）。
「じゃあどんな風に書けばいいんですか？」
って（半分キレ気味に）聞いたら、
「なんかテーブルみたいの作ってさぁ、～」
と、それだとどう考えてもソースの量３倍＆実行時間３倍くらいは
想定できる事を言われて、めっちゃ呆れた記憶が。
＃ええ、もちろん最終的に喧嘩別れですよ。
＃（自分の）会社には、ちゃんと謝りましたけど。
Re:あったけど (スコア:1)
＞あと、気持ちは察するけれど、簡単に理解できるプログラムを書くこともお仕事なのよね。
＞システムの規模が大きくなればなるほど、開発や保守に携わる人間のスキルもまばらになってくるので、
＞それを踏まえて「処理速度の早いプログラム」より「誰もが読めるプログラム」が求められる状況は多々ある。
正にそれを言われました。「誰もが読めるプログラムを書いて」って。
ただ、当時の僕には、どうしても「頭使えば理解できるだろ！？」って考えの方が強くて・・・
何が悲しくて「サルでも分かるプログラム」を書かなきゃならないんだって思っちゃいました。
今思えば、若気の至りではありましたね。
＃転職した理由も、まさにその通りです。そこの会社だと、どうしても某社の影響下なので。
Re:そのレビュアーが (スコア:2)
レビューばかりやってると、「こんなレベルで持ってくんな！」と門前払いしたくなる時があります。
目立つ所（coding syntax など）を先に潰さないと読むに耐えないというわけで。
インデントやフォントに着目される時点で、「レビューを受けるレベルに達していない」ことをレビュイーに
自覚させなければいけません。
本人が自覚できるよう口酸っぱく言うのもレビュアーの役割だと思うので、それが浸透していないことは
レビュアーの落ち度でしょう。
---- 何ぃ！ザシャー
Re:そのコーダが (スコア:1)
＞ドキュメントレビューならばフォントの指摘はごく当然。
ドキュメントでフォントが指定されているという時点でダメでしょう。
DocBook でも、DITA でも FrameMaker でも、
ドキュメントの本体にフォント指定なんて必要ありませんよ。
PDF や HTML にした場合のフォントが云々は、ドキュメントレビューじゃなく、
印刷デザインとかウェブデザインのレビューでやるものだと思います。
Re:コーディング規約ではないですが (スコア:1)
Re:Tab or Space? (スコア:2)
Tabで統一したくても、スペース使う人がいると、Tabとスペースが混ざって最悪になってしまう。
Tabをスペースに展開するのは機械的にできるけど、逆は難しい。
以上の理由から、保存時にuntabifyするように設定させて、スペースでのインデントを徹底してます。
一人でコーディングするときはTabを使いますけどね。