アカウント名:
パスワード:
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。 ケースバイケースですが、これはちょっと断定しちゃうのは反対。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ? いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。 # 差分なんてツールで漏れなく正確に判るんだって!
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
>>ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。>目grepはツールに入りますか?まったくです。
ソースだけで変更管理しようとすると、人間の目視では把握できなくなるんだってば。
こんな感じでswitch( a ){case 1:
case 10:
case 2:.....case 100:
default:}
/* 2001年10月31日修整// 修整理由なんたらかんたらswitch( a ){case 1:
case 3:.....
default:}*//* 2003年10月31日修整// 修整理由なんたらかんたらswitch( a ){case 1:
case 2:.....
// 2003年1月10日修整// 修整理由なんたらかんたらcase 18:.....
//
default:}*/
/* 2005年2月31日修整 // わざとですswitch( a ){case 1:
100行以上はある細切れの大量の修正前コードの中に、数行の最新コードが埋もれているのを実際に見たことがあります。基本的に修正前コードは増え続けるのに対して、機能追加しない限り最新コードはそんなに増えないですからね。時間が経てば経つほど修整すればするほど、ソースのカオス化は進んでいきます。
そういえば、エディタによるコメントの色分けはツールに含まれないんですかね?
他人のソースなんて、よくわかんないから、とりあえずgrepして読んでいったりするから、ヘタにコメントアウトでダミーを量産してもらうと邪魔で仕方がない。検索して見つかったやつを一生懸命読んでいて、ふと上の方をみると #if 0 とかかかれていたときの絶望感はすごい。
ところが、コメントでソース残す古い人は平気でそういうことやるから困るちょっと前までは
「バージョン管理なんて信用できない」「古いソースがソース内にあったほうが効率がいい」
とかなんとか言って汚いソースで書いてたが、if文やcase文とかでコメントアウト部分とソース部分が入り乱れているのをみて「なんとかなる」とか言い放ちやがって、あの○○野郎!
…と一時期本気で喧嘩売ろうかとおもったが、うちの部署はすっかりツールが整備されたので今は不満がない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
あんまし関係がないと思う (スコア:4, すばらしい洞察)
文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
「美しい」コードだったりします。
むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。
コメントもコードも「言語」ですからね。
#ってか、「非プログラマ」な人種はソースなんて見るのか?(<俺)
---- ばくさん!@一応IT土方
Re: (スコア:0)
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
Re: (スコア:0)
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ?
いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。
# 差分なんてツールで漏れなく正確に判るんだって!
Re: (スコア:0)
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。
それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
Re: (スコア:0)
Re:あんまし関係がないと思う (スコア:1)
>>ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
>目grepはツールに入りますか?
まったくです。
ソースだけで変更管理しようとすると、人間の目視では把握できなくなるんだってば。
こんな感じで
switch( a ){
case 1:
case 10:
case 2:
.....
case 100:
default:
}
/* 2001年10月31日修整
// 修整理由なんたらかんたら
switch( a ){
case 1:
case 3:
.....
case 10:
default:
}
*/
/* 2003年10月31日修整
// 修整理由なんたらかんたら
switch( a ){
case 1:
case 2:
.....
// 2003年1月10日修整
// 修整理由なんたらかんたら
case 18:
.....
//
case 10:
default:
}
*/
/* 2005年2月31日修整 // わざとです
switch( a ){
case 1:
case 10:
case 2:
.....
default:
}
*/
100行以上はある細切れの大量の修正前コードの中に、数行の最新コードが埋もれて
いるのを実際に見たことがあります。基本的に修正前コードは増え続けるのに対して、
機能追加しない限り最新コードはそんなに増えないですからね。時間が経てば経つ
ほど修整すればするほど、ソースのカオス化は進んでいきます。
そういえば、エディタによるコメントの色分けはツールに含まれないんですかね?
Re:あんまし関係がないと思う (スコア:1)
他人のソースなんて、よくわかんないから、とりあえずgrepして読んでいったりするから、ヘタにコメントアウトでダミーを量産してもらうと邪魔で仕方がない。
検索して見つかったやつを一生懸命読んでいて、ふと上の方をみると #if 0 とかかかれていたときの絶望感はすごい。
by rti.
Re: (スコア:0)
case文の中にコメントアウトされてんのとされてないのが入り乱れてくるとそろそろヤバくなってくるが。
Re:あんまし関係がないと思う (スコア:1)
ところが、コメントでソース残す古い人は平気でそういうことやるから困る
ちょっと前までは
「バージョン管理なんて信用できない」
「古いソースがソース内にあったほうが効率がいい」
とかなんとか言って汚いソースで書いてたが、if文やcase文とかでコメントアウト部分と
ソース部分が入り乱れているのをみて「なんとかなる」とか言い放ちやがって、あの○○野郎!
…と一時期本気で喧嘩売ろうかとおもったが、うちの部署はすっかり
ツールが整備されたので今は不満がない