いいコーディング規約、悪いコーディング規約? 231
ストーリー by soara
とりあえず indent してみた 部門より
とりあえず indent してみた 部門より
Anonymous Coward曰く、
本家Slashdotに聞け!「Best and Worst Coding Standards?」より
/.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか? 逆に規約のせいで問題が起きてしまったケースなどあるだろうか? 他にも、使える「自分ルール」などもあれば是非。本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。
可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか? ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか?
コメントで残す (スコア:5, おもしろおかしい)
「変更する場合には、変更前のコードを全てコメントで残して日付・変更者を記載すること。」
バージョン管理システムを使おうよ…
HIRATA Yasuyuki
Re:コメントで残す (スコア:2, すばらしい洞察)
これに一票. これに比べれば, どれほど変な規約でもかわいいものです.
21世紀に入るまで, こんなバカ規約が存在することを知りませんでした. 私が会社を辞める原因になったと言っても過言ではありません. しかも巨大システム開発ほど, この規約を採用しているケースが多いので, 数兆円規模の損失の元になっているでしょう.
Re:コメントで残す (スコア:2, 興味深い)
「関数名は連番」に比べても、ですか?
私は両方体験しましたが、どちらも許せませんでした。
Re:コメントで残す (スコア:2, おもしろおかしい)
# 理由は「引数を理解できない開発者がいるから」らしい
Re:コメントで残す (スコア:2, おもしろおかしい)
#define NOT_PIYO
( ゚д゚)
_(__つ/ ̄ ̄ ̄/_
\/ /
( ゚д゚ )
_(__つ/ ̄ ̄ ̄/_
\/ /
//実話
Re:コメントで残す (スコア:2, おもしろおかしい)
なんのためにバージョン管理使ってるんだかわからなくなります・・・。
Re:コメントで残す (スコア:1)
「バージョン管理使ってるんだからコメント履歴止めましょう!」って何度かかけあったら廃止の方向に向かってくれた。
Re:コメントで残す (スコア:3, 興味深い)
ソース「そのもの」はバックアップするが、
バージョン管理のリポジトリはバックアップしない(するに値すると理解してない)
という恐れがあるので気をつけるべしh。
いちいちチェックアウトしたもの「を」バックアップするのね。まあなんというか、自動車を見て「手綱はどこだ」とか訊いたという古代人のようなもんだ。新しいツールの「根本」を理解してない。
それはそうと。自衛策として、
つまりもしリポジトリが飛んだら会社も困るが開発した自分らも(萎えるし仕事が増えるから)困るので、
私はそういう場合は自分で勝手にバックアップすることにしてる。
幸い最近は普通に安く買えて使えるローカルPCのHDDが余り気味であることが多いので、
自分のPCのその余力でもって、リポジトリをバックアップしとくのだ。
ついでにドキュメント"サーバ"のバックアップも同様に"クライアントPC"に取っておくのがお勧めだ。
奴らのバックアップなんて信頼できん。「過去1週間だけ残してあればいい」なんて平気で言う奴らだからな。(それって2週間前に人知れず起こったデータ破壊には無力じゃん!)
それにバックアップ自体が有ったとしても取りだしが容易ではない(手続きを要したりツールが煩雑だったり)可能性も警戒すべきだ。
だったら自分とこでバックアップを走らせればいいんだ。もちろん使い易いツールを自分で選んでね。
サーバとクライアントの関係が逆じゃないか!と思う人は頭が固い。使えるHDDなら猫のHDDだって使う。残存したファイルが官軍。それでいいんだ。
あとクライアントはたいてい複数あるから、
同じバックアップを複数のクライアントでやればそれだけで冗長性が確保できるぞ。
Re:コメントで残す (スコア:2, おもしろおかしい)
そのうちセキュリティー対策でローカルHDDとUSB端子のないPCになりますよ。
規約以前 (スコア:4, 興味深い)
# あー、のど元まで愚痴が出かかってる。
たとえコンパイルが通ってもエディタなどが解析できる程度に。Emacsのcc-modeとかね。
# //形式の正規表現中にエスケープされない/が入ってて凹んだ。
逆に、このレベルとなるとコンパイラの警告とかは読んでも理解できないから、警告を消せとは怖くて言えない。
# 引数が足りないと言われるととりあえずnull突っ込まれたりする。
実例かどうかは、ご想像におまかせします。 (スコア:3, 興味深い)
実際にコーディングする人間からすると、意味不明なのがチラホラ。
前任者が作ったプログラムを見ると、確かに、コーディング規約は守ってたが、暗黙の前提・常識は守って無かった……つまり、絵に描いたようなスパゲッティーコードだった、と。
既存のプログラムを改修しようとすると、エラい事に……。
殺意と言うのが、どんな時に湧くのか、良く判りました。
燃料投下 (スコア:3, おもしろおかしい)
着火 (スコア:1)
三項演算子がないとテンプレートメタプログラミングがー。
indent を使え (スコア:2, 参考になる)
fjの教祖様
悪い規約の問題はもみ消され続けてます (スコア:2, 興味深い)
起きればまだいいんですけどね。タイトル参照orz
一番判り易いところでいえば、
「関数名やファイル名は連番!」とかね。
名前の意味から、その参照先が何者なのかを、察することは不可能です。
(暗記することは出来るかも知れないがね。ああいう現場では発想力より暗記力が強い奴のほうが幅を利かせる…orz)
で、それに起因する「問題」ですが、
彼ら(の老害重役どもだと思われるが)は
それが好きでやってるわけだから、
それで「問題」が出ても、無かったことにされます。
無かったことにするのは簡単ですよ。
「それよりマシな生産性」を観測しなければいいんですから。
つまり普通のネーミングを絶対許さなければ、
それ以上生産性が良くなるとどうなってしまうのか?を
(心ある一部の人以外は)気づかず終わります。
昔からそうでした。今もそうでした。私が知ってるだけで5年ですまないだけの時間、彼らはそうしています。きっともっと前からそうだったんでしょう。
#某有名企業の内情なのでAC
#それこそ隠れた損失は数兆円だったりしないだろうか…
「コメントを書け」と言われても... (スコア:2, 興味深い)
おかげでクラス名・メソッド名だけのjavadocができてきて、何の役にも立ちゃしないorz
100万歩ゆずって、一般の開発部隊の成果物がそうであっても許してあげようかなという気にもなるが、それが基盤・ツール部隊の作ってる汎用部品だったりするともうねぇ...
やっぱ「規約」で縛るだけじゃなくって、「なぜそうしなければならないのか」をみっちり教え込まないとダメっすよ。>だれともなく。
規約の見直しについて言及されていない規約 (スコア:2, 参考になる)
あとは、プロジェクト内でもコアな部分を作るチームと、
それ以外のチームは分けて欲しいなと思ったりすることが多いです。
いいコーディング規約は死んだコーディング規約だけだ (スコア:2, 興味深い)
叩き台に実際にコーディングする人たちで膝突き合わせて話し合えばそこそこ現実的な規約になるかと。
まあ実際は「客の規約に合わせます ホントにアレなとこだけ一応文句言ってみます」になりがちだけど。
空気読まずに書いてみる (スコア:2, 興味深い)
わたしもいくつかありますがなによりも重要なのは
"規約を決めたなら徹底的に守らせること"
たとえゆがんだ規約であっても、コーディングが確実に
規約に則っていればある程度までは保守できます・・・と思いたい。
まずはタレこみから始めよ (スコア:1, おもしろおかしい)
○ガイドライン
メンテ性(←推奨されない)
修正しました (スコア:1)
MIYAZAKI Yasushi
さっそくエサ投入 (スコア:1, 参考になる)
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [googlecode.com]
その訳
http://www.henshi.net/k/hiki.cgi?GoogleCppStyleGuide [henshi.net]
#C++のコーディング規約といえば、fool-proofに傾けてるのが多いよな・・・
ほとんど無い (スコア:1, すばらしい洞察)
・インデントはTabで。
・テクニックに走らず、誰が見てもわかりそうな構文で。
・できるだけ省略しないで書いて。
命名規則とかは、今の会社では無いですね。
Re:ほとんど無い (スコア:2, すばらしい洞察)
何をしているのか、ではなく、何故なのかを書けって教わりました。
そのため関数の先頭にコメントをたくさん書くようになりました(if,for等のブロックを扱うレベルで言及はあるけど)
仕事としてのプログラムを習いたての頃は"初期化する"とか後で訳のわからなくなるコメントが多かったので非常に勉強になりました。
#大人になったら何をしてるのかはコードに書いてあるってよくわかるようになったよ
Re:ほとんど無い (スコア:2, 参考になる)
良い環境ですね。良い上司、良い先輩…
悪い環境では「何を」を逐一書かないとレビュー通りませんから。
ええ。わざわざレビューでもってコードを劣悪化してるわけです。これも損失数兆円?
あと振る舞いばかり気にする連中も困る。
つまり振る舞いにはコメント逐一入れさせるいっぽうで、
変数にはコメントつけないのな。
どっちかというと、変数に「これは何か」ってコメントをつけてくれると、
そのあとのその変数の人生が想像できて、追い易いんだけどな。
こういう、「人生を想像」みたいな一種の児戯っぽいものが、実は一番人間の脳にとっては易しくて、そのぶん便利なんだよ。
Re:ほとんど無い (スコア:3, おもしろおかしい)
a = 10; /* 変数aに20を代入 */
HIRATA Yasuyuki
Re:ほとんど無い (スコア:1)
7文字制限なんて遠い昔だな。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ほとんど無い (スコア:1, 興味深い)
何をもって「テクニックに走った」と呼ぶか?がまちまちなんで困るんですよね。
例えばRuby畑(の外側)で時々聞く、「RubyのBlockは使わない。イテレータ使わない。for文でやる」という奴。
私は、そんなことしたらRubyのうまみの8割が消し飛ぶ、
(だってそれじゃVBと字面そっくりじゃん。だったら素直にVB使えよ)
つまりRubyにBlockは「必須」だと思うのですが、
あれを「テクニックだ。誰が見ても読めるってわけじゃないから却下」する人らも居るようです。
#宝の持ち腐れだと思うぞー?
#Rubyのうまみは突き詰めればリテラルだろ。正規表現リテラル、(埋め込みが出来る)文字列リテラル、Rangeリテラル、そして関数リテラルもどきのBlock、などなど。
#あとはメタプログラム系かな。
#OOPなんていまどき当たり前なので騒ぐだけ野暮。
Re:ほとんど無い (スコア:2, 興味深い)
> 何をもって「テクニックに走った」と呼ぶか?がまちまちなんで困るんですよね。
これには深い意味があって、
・周りのメンバの力量が計れない人は、チームを組んでもうまくやっていけない
って所の裏返しです。
先に上げた4つの規約も、大雑把にいえば「協調性・思いやりを持ちましょう」程度の事です。
これが無いと、例えずば抜けた能力があってもうまくいかないです。
Re:ほとんど無い (スコア:1)
私のプログラムのコメントというかバージョン管理システムの更新履歴に
全て「にょろーん」って書いてあるのは内緒です。
当然ながら、誰にも公開してないプログラムですよ
Re:ほとんど無い (スコア:2, すばらしい洞察)
Re:ほとんど無い (スコア:1, 興味深い)
ここで紛糾するんだよね。C言語限定だと
if(pointer==NULL||*pointer='\0')って書いて「NULLポインタを参照するなよ」っていわれるとか。
「for(p = buf; *p; ++p)」って書いて「for(i = 0; i < strlen(buf); i++)にしろ」と怒られるとか。
「sprintf(buf, "%*d", digits, num);」って書いて訳分からんと怒られるとか。
3項演算子のことは知りません。
俺的ガイドライン (スコア:1)
表示は4スペース。
異論は認めない。
#スタンドアローンな開発は楽だねぇ。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:俺的ガイドライン (スコア:1, おもしろおかしい)
#古いモジュールはFORTRAN77...
ごめんなさい。 (スコア:1)
# 自分でもヒデェスパゲッティなコードだと思う。コメントしようがない所ばっかだしorz
こればっかじゃアレなので。
良い規約:書き易い、読み易い(意味の取りやすい)、改変し易い、間違い(スペルミスからアルゴリズムの間違いまで)が分り易い、そしてそのために合理的で無駄はない。
といいな。とか思うのですが、現実はそこまでいきませんねぇ。
# あと、規約にプログラムの構造に踏み込んだような記述がありますが、あれについては微妙かなとも思う...
## できぬおバカのワガママと自戒しておりまするぅ。
M-FalconSky (暑いか寒い)
整形ツールを作ったり (スコア:1)
簡単なのは秀丸マクロで出来るし、単なるスタイルなんて変換すればいいだけ。
自分的に大事なのはgrepとかのツールで参照や使用を簡単に把握できたり、置換で一気に変えたりできること。
その為にはクラス名と変数名のように関連のあるものは一貫性のある変換ルールにする方がよい。
折角、自動化して生産性を向上し易い環境なのだから利用しない手はない。
Re:整形ツールを作ったり (スコア:1, おもしろおかしい)
と言ってみるテスト
Re:整形ツールを作ったり (スコア:1)
昔はC言語レベルの構文解析を行って関数単位でリスト構造に変換してソース生成を行うというスタイルコンバーターを作ったりしていました(^^;
肝はコメントも構文の一部とすることでスタイルだけを変えられるようにしているところですが、たまに想定から外れたコメントが消えたりしたような気がします(^^;
Viewは使わない (スコア:1, おもしろおかしい)
Re:SVO とか SVC とか (スコア:3, 参考になる)
関数名が日本語ローマ字になっていて恥ずかしくて公開出来ないのがあるとかないとか。
int is_wakuno_naka(int x, int y);
Re:SVO とか SVC とか (スコア:5, おもしろおかしい)
じゃあどうせいっつったら「Concatenateにしろ」だって。頭おかしいんじゃないかね。Concatenateって言われて誰がわかる?
これはスクリプト言語の行を連結するって言う処理なんだけどね、それをただ「Append」にしたら、お前「Append」には標準で意味がついてるだろ。
それと同じ意味と誤解されるだろ。スクリプト言語の行連結処理は、そんなに簡単なもんやないぞと。
特に俺のは、行連結が三種類もあって、既存言語にはない概念だからね。既存のものにないっていうのをはっきりと示すために、
Renketu、SuperRenketu、SpecialRenketu、と名づけた。もう忘れない。この特殊な処理を。
どうしてそういうことも考えず、ローマ字=ダサいみたいな固定観念でいられるのかねえ。成長する気がないんだろうな。
Re:SVO とか SVC とか (スコア:1)
# 作った事があったけど漢字変換が面倒になって使わなくなった。
Re:SVO とか SVC とか (スコア:1)
後日読んだら意味不明で結局巻数の中まで読む羽目に。
懲りて今では和英辞書ひいてます。
シャアは (スコア:1)
Re:SVO とか SVC とか (スコア:3, 興味深い)
if (x.is_ascii())と書いて、「if x is ascii then」と読む感じで。
あとは、bool 値を返すようなメソッドで、
関数名の命名でやってはいけないのが、boolを返すのにどっちがtrueかわからない様な動詞の使い方。
asciiかどうかチェックする関数を check_ascii って命名しちゃうと、
if (check_ascii(x)) {
ってコードは ascii の時と非asciiの時のどっちで実行されるのかぱっと見わからないので可読性がすごく落ちます。
それと、メソッド名を「V O」にするか「O V」にするかは悩むんですよね。
file_write と write_to_file だと、英文的には後者の方が分かりやすいんですが、それとは別に
file_read あるいは read_from_file があった場合、「write_to_fileとread_from_file」より
「file_writeとfile_read」の方が、関数一覧で見たときに組になってることが分かりやすいので。
理想的には、オブジェクト指向的に、O の方はオブジェクトを渡すようにして、
メソッド名は V だけに徹しなければいけないんでしょうけど、なかなかそうもいかなかったりして…
前置、後置、倒置 (スコア:2, 興味深い)
オブジェクト(S)がメソッド(V)でもって引数を(O)食って返り値(C)を吐く!
ところが修飾語だけはラテン語系(suffix)がよいようです。prefixやると後で死ねるので気をつけましょう。
$green_apple $red_apple $white_apple よりも $apple[rouge] $apple[noir] $apple[blanc] だよね
# ソビエトロシアでは規約がプログラマをコーディングするっ!! [ansaikuropedia.org]
# コーディングする人ってヨーロッパ言語の文法覚えるの得意そうなもんだけど(フレームのもと)
Re:SVO とか SVC とか (スコア:1, おもしろおかしい)
わ、わたしじゃないんだからねっ
Re:80桁自主規制 (スコア:1)
130前後で手を打ちたいのですが、80以外の数字に
通りのよい根拠が流通していないせいもあって、なかなか規約
として表明しにくいところなんですよね。
#ちなみに言語はJava
##細かい整形規約は、Eclipseのフォーマット機能とorganize-import機能に任せる方向で。
Re:NGワード (スコア:1, 興味深い)
Hogehogeの実体と、その情報のみを収めたものと、複数のHogehogeを管理するもの全てにHogehogeって付けるの?
私だったらHogehoge / HogehogeInfo / HogehogeManagerみたいに使い分けるけどなぁ。
Re:コーディング規約なのか (スコア:2, おもしろおかしい)
一度 defautl: と打ってしまうと次も defautl: と補完されてしまう悲劇。