アカウント名:
パスワード:
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。 ケースバイケースですが、これはちょっと断定しちゃうのは反対。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ? いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。 # 差分なんてツールで漏れなく正確に判るんだって!
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
# ○○な処理。。。なんだけど、うまく動かない。
ってコメントには怒りを通り越して笑うしかない(笑) 詳細なコメントは、それ自体へのメンテナンスコストがかかるので、コメントが不要なくらいに理解しやすいコードを書くというほうに努力すべきだと思います。 # 昔 Linux-Users-ML でそんなスレッドがありましたよね。
元コメじゃないけど、
>コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?もちろんです。
>setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。その通りです。「下手なプログラマは存在自体が殺人的である」という事実を理解して頂けて幸いです。
他にもgetなのに副作用があったり、勝手に内部でカウントアップしたりくらいは日常茶飯事。なんとかmanagerとかなんとかControllerって書いてあるけど、何をどのように管理するのかサッパリわからないとかもよくありますね。http://www.radiumsoftware.com/0603.html#060330 [radiumsoftware.com]
コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?
うん、基本的に信用していない。
setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
get~()って関数が値を設定していることはザラだし、isFoo()って関数が予想とは逆の値を返すこともよくある。
自分の書いたコード以外は信用できないし、自分の書いたコードはもっと信用できない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
あんまし関係がないと思う (スコア:4, すばらしい洞察)
文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
「美しい」コードだったりします。
むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。
コメントもコードも「言語」ですからね。
#ってか、「非プログラマ」な人種はソースなんて見るのか?(<俺)
---- ばくさん!@一応IT土方
Re: (スコア:0)
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
Re: (スコア:0)
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ?
いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。
# 差分なんてツールで漏れなく正確に判るんだって!
Re: (スコア:0)
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。
それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
前の業者が逃げたあとの尻拭いをしたことがあります。つか、継続中だけど。
当然、そんな奴らの書いたコメントが当てになるはずがありませんので、邪魔な先入観を与えるだけのコメントなら、ないほうがマシという状況です。
正直
ってコメントには怒りを通り越して笑うしかない(笑)
詳細なコメントは、それ自体へのメンテナンスコストがかかるので、コメントが不要なくらいに理解しやすいコードを書くというほうに努力すべきだと思います。
# 昔 Linux-Users-ML でそんなスレッドがありましたよね。
Re: (スコア:0)
コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?
setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
始めて見るコードなのにバグの原因に即答を求められる、これは私の職場が悪いんでしょうか。
一番信用してないのは、仕様書と設計書です。
無くてもいいんじゃないかとよく思います。
Re:あんまし関係がないと思う (スコア:2, すばらしい洞察)
元コメじゃないけど、
>コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?
もちろんです。
>setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
その通りです。
「下手なプログラマは存在自体が殺人的である」という事実を理解して頂けて幸いです。
他にもgetなのに副作用があったり、勝手に内部でカウントアップしたりくらいは日常茶飯事。
なんとかmanagerとかなんとかControllerって書いてあるけど、何をどのように管理するのか
サッパリわからないとかもよくありますね。
http://www.radiumsoftware.com/0603.html#060330 [radiumsoftware.com]
Re:あんまし関係がないと思う (スコア:2, すばらしい洞察)
うん、基本的に信用していない。
get~()って関数が値を設定していることはザラだし、isFoo()って関数が予想とは逆の値を返すこともよくある。
自分の書いたコード以外は信用できないし、自分の書いたコードはもっと信用できない。
Re:あんまし関係がないと思う (スコア:1)
たとえば count_i という関数が何をやっているかわかりますか?
たとえば name1 という変数名が何を表すか答えられますか?
信用するとかしないとか以前の問題がそこにはあり、リーサル・ウェポンと呼ばれていた奴が実在するわけですよ。
Re: (スコア:0)
それに、拡大解釈すれば全てのバグは名前の意図と実際のコードの食い違いと見なせるんじゃなかろうか。
--
名前は嘘を付くがコードは嘘を付かない。但しコンパイラ・実行環境のバグを除く。