アカウント名:
パスワード:
> 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば> 「美しい」コードだったりします。
内容は賛成ですが、万人にはお勧めできないと思います。「自称」やり手プログラマの中には、コメントがなければ美しいコードだと勘違いしている人がいるようなので。
以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、「コメントがなくてもわかりやすく書いてある」と言っていたのですが、そのソースコードの不具合改修をお願いすると「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」と言ってました。そのためのコメントじゃないの?
同様に「プログラマならemacsだろ!IDEなんか必要ない!」みたいな考え方の人もどうかと思います。
> そのためのコメントじゃないの?
コメントが書かれているからといってプログラムを解析する手間がなくなるわけじゃない。
だってコメントが書いてあってもそれが正しいという保証はない。
だから必ずコメントとコードが整合しているかチェックしなくちゃいけないけど、これがコードを直接、解析するより楽かどうかはコメント(とコード)の品質による。
「優れたコメントは優れたコードと同じくらいプログラムにとって重要だ」
という言葉を聞いたことがある。(ストールマンがいってたような…)
しかし私は言おう。
「劣悪なコメントは凶悪なバグと同じくらいプログラムにとって有害だ」
と
>「自称」やり手プログラマの中には、>コメントがなければ美しいコードだと勘違いしている人がいるようなので。こっちの指摘はまあまあ理解できるけど、
>そのためのコメントじゃないの?それは必ずしも正しくないと思う。コメントがあった方が良い局面というのはあるけれど、コメントがあればデバッグのためのソースの解析が不要になるかというとそんなことはない。
たとえ自分が書いたプログラムやコメントでも、書いてから何年もたてば自分が書いた内容の細部なんて忘れてしまいます。まして自分が当時気付かなかったミスについて修整を頼まれたんだから、自分が当時正しいと思っていた仮定なんてあてになりません。
例えば,自分で書いた推理小説の密室トリックのアラを読者に指摘されて、推理小説の辻褄があうようにトリックを書き直そうと思えば小説全体を読み直して書き換える必要がある。それには相応の時間がかかるのは避けられないと思います。
>同様に「プログラマならemacsだろ!IDEなんか必要ない!」みたいな考え方の人もどうかと思います。
「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。しょせんIDEなんて、単体のツールを集めただけの代物なんだから。
むしろ「IDEさえ使えればいい」、「単体のエディタなんて時代遅れだ」と思ってる人の方がどうかと思います。そういう人はIDE付属の簡易エディタしか使ったことがなくて、本物のエディタを理解していないんですね。酷い場合だと除き窓のような細いエディタ領域の中から、横長で改行も入ってないようなコードを書いて平然としている人までいます。機能単位で関数を分けると分散して読みにくくなると文句を言う人もいます。
あとJavaのように強力な型付けの言語で、それをIDEが解析して利用している場合ならまだしも、Rubyのように動的な片付けの言語や、PHPのようにぐ支離滅裂な言語だと、IDEの単体エディタに対する利点はかなり減るでしょうね。
> スクリプト言語でも、IDEを使うとプログラムの処理をブレイクポイントで止めたり> その時点の変数の中身を見たりってことが簡単にできるので有益だと思います。
やり玉に挙げられていたEmacsでもできますけど。むしろIDEなんてなかった時代からEmacsではできてました。
あー、またですか [srad.jp]どっちもどっちなような
emacs にしても大昔は重すぎだ巨艦大砲主義だと今の IDE みたいな扱いをされてたわけで#複数立ちあげてると叱られましたよ
三角形内点判定になんで直線交差チェックが要るんだ?外積符号判定じゃないのか?
処理をコメントに書くから変なのでは?コメントに
// 交差判定し、~の場合に~する
と書けばよいこと。細かい実装(アルゴリズム)の勉強はコメントを見れば「そうか、交差判定の方法を調べればいいんだな」となります。これが「交差判定」の語がなければ、知らない人は脳内ステップ実行して動作から目的を導出しなくてはならず、解読不可能でしょう。
> 自分と同じ数学やプログラムの知識が無い人間がプログラムを読んだときに、> 処理内容がわかるプログラムを書いているなら、自称が取れると思う。この辺、永遠のテーマですね。
「プログラムの知識が無い人間」って、要するに全人類だろってことになっちゃいますし。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
>> あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。>> バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
>ケースバイケースですが、これはちょっと断定しちゃうのは反対。>修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
十数年前だったら、それも一利あったかもしれない。当時でも否定する意見は多かったけど。
今だとこれはバージョン管理システム&バグトラッキングシステムで行うべきもの。未だにそれを導入してない/導入したけど使ってないというのは、バカがすること。
「日本ではバカが非常に多い」という点については、残念ながらその通りというほかない。
過去のバージョンとdiffとってみて。たぶんエライコトなってるから。
やってるときは前のコードも見てたいしw
ファイルのコピー残しとけば良いんじゃ...
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。 ケースバイケースですが、これはちょっと断定しちゃうのは反対。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。 バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ? いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。 # 差分なんてツールで漏れなく正確に判るんだって!
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
そういう場合はツールを使わなくても結局同じような悲劇が起こるので安心してください。
#宗教論争をするのは「神様を信じる人」であって、神様自身は論争しない
> ツールを使いたくないのであればプログラマーとかIT業界にいないで転職した方が良いと思います。
少し違うかも。
有用なツールを使って生産性を上げる、この指向なり志向なりは大切ですが、その生産性の向上が局所的な場合もあるのでは、と思いますね。
元の話は修正前の元コードをコメントアウトして残すや、バグ票番号を修正位置に残すのが是か非か、ですよね。非の方の意見は、diffやVCSやBTSを使えばその様なものをソースコードに残す必要は無い、だと思います。
元コードをコメントアウトはどうかと思います。が、例えば改修コードをトレースして確認する場合、そのトレースツール(シンボリックデバッガとか)が連携しているのはソースコードであってdiffやVCSやBTSでは無いでしょう。となれば、diffやVCS/BTSログ(ログに位置が記してあれば、ですが)のプリントアウトとかが必要となって、紙の無駄ではないかと。
やはり一概にugryとは言えないと思いますが。
えー・・・ネタだよね? 一応突っ込んどくけど、
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。 それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。 ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
「共有フォルダに最新ソースがあります。修正前後の差分はコメントを見れば判ります。」 と言われて引き継いだら、src_20091117 と src_最新版 と src_最新 フォルダがあったらどうしますか? ついでに、コメントは基本的に適当デタラメだったらどうしますか?
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。 あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
バージョン管理システムやバグ管理システムは、作成者が更新しますが、最終的に管理者が管理するものですよ。 管理者の人が管理しなかったら、作成者にしかわからない状態になりますが、それは自業自得ですね。
# ちなみに全部実話です(涙
「共有フォルダに最新ソースがあります。修正前後の差分はコメントを見れば判ります。」と言われて引き継いだら、src_20091117 と src_最新版 と src_最新 フォルダがあったらどうしますか?ついでに、コメントは基本的に適当デタラメだったらどうしますか?
言いたいことは判らなくもないけど、バージョン管理システム導入してても適切に運用されてなければ似たようなことは起こります。好き放題ブランチ切られた挙げ句収集がつかなくなるとか。
↑で書かれてることは「ルールが規定されてないor遵守されてない」ことに起因する問題なので、ソースの可読性云々とは少しブレてるんですよね。
・diffを使うのはずるい・それは実力ではない・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。・ツールを使うのはズルとしているのを同じということでしょうか [okwave.jp]
# ○○な処理。。。なんだけど、うまく動かない。
ってコメントには怒りを通り越して笑うしかない(笑) 詳細なコメントは、それ自体へのメンテナンスコストがかかるので、コメントが不要なくらいに理解しやすいコードを書くというほうに努力すべきだと思います。 # 昔 Linux-Users-ML でそんなスレッドがありましたよね。
元コメじゃないけど、
>コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?もちろんです。
>setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。その通りです。「下手なプログラマは存在自体が殺人的である」という事実を理解して頂けて幸いです。
他にもgetなのに副作用があったり、勝手に内部でカウントアップしたりくらいは日常茶飯事。なんとかmanagerとかなんとかControllerって書いてあるけど、何をどのように管理するのかサッパリわからないとかもよくありますね。http://www.radiumsoftware.com/0603.html#060330 [radiumsoftware.com]
コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?
うん、基本的に信用していない。
setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
get~()って関数が値を設定していることはザラだし、isFoo()って関数が予想とは逆の値を返すこともよくある。
自分の書いたコード以外は信用できないし、自分の書いたコードはもっと信用できない。
やだ、何言ってるのこの人・・・。正気とは思えないんですけど。
>>ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。>目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文とかでコメントアウト部分とソース部分が入り乱れているのをみて「なんとかなる」とか言い放ちやがって、あの○○野郎!
…と一時期本気で喧嘩売ろうかとおもったが、うちの部署はすっかりツールが整備されたので今は不満がない
9割が変更履歴のソースコードを読みたいんですか?システム化したほうがいいところはシステム化するのがシステム屋の仕事じゃないですか。
色々突っ込みたいが一言でまとめるなら、
>検証をするのに残すべき
それで「検証」になると思うとは御目出度いね…ってとこです。
#まあ某ITゼネコンはそれを検証と呼ぶに値すると本気で思っているようだけども。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
あんまし関係がないと思う (スコア:4, すばらしい洞察)
文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
「美しい」コードだったりします。
むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。
コメントもコードも「言語」ですからね。
#ってか、「非プログラマ」な人種はソースなんて見るのか?(<俺)
---- ばくさん!@一応IT土方
Re:あんまし関係がないと思う (スコア:4, すばらしい洞察)
> 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
> 「美しい」コードだったりします。
内容は賛成ですが、万人にはお勧めできないと思います。
「自称」やり手プログラマの中には、
コメントがなければ美しいコードだと勘違いしている人がいるようなので。
以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、
「コメントがなくてもわかりやすく書いてある」
と言っていたのですが、そのソースコードの不具合改修をお願いすると
「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」
と言ってました。
そのためのコメントじゃないの?
同様に「プログラマならemacsだろ!IDEなんか必要ない!」みたいな考え方の人もどうかと思います。
Re:あんまし関係がないと思う (スコア:2)
> そのためのコメントじゃないの?
コメントが書かれているからといってプログラムを
解析する手間がなくなるわけじゃない。
だってコメントが書いてあってもそれが正しいという
保証はない。
だから必ずコメントとコードが整合しているかチェックしなくちゃ
いけないけど、これがコードを直接、解析するより楽かどうかは
コメント(とコード)の品質による。
「優れたコメントは優れたコードと同じくらいプログラムにとって重要だ」
という言葉を聞いたことがある。(ストールマンがいってたような…)
しかし私は言おう。
「劣悪なコメントは凶悪なバグと同じくらいプログラムにとって有害だ」
と
Re:あんまし関係がないと思う (スコア:1)
>「自称」やり手プログラマの中には、
>コメントがなければ美しいコードだと勘違いしている人がいるようなので。
こっちの指摘はまあまあ理解できるけど、
>そのためのコメントじゃないの?
それは必ずしも正しくないと思う。
コメントがあった方が良い局面というのはあるけれど、コメントがあればデバッグのための
ソースの解析が不要になるかというとそんなことはない。
たとえ自分が書いたプログラムやコメントでも、書いてから何年もたてば自分が書いた
内容の細部なんて忘れてしまいます。まして自分が当時気付かなかったミスについて
修整を頼まれたんだから、自分が当時正しいと思っていた仮定なんてあてになりません。
例えば,自分で書いた推理小説の密室トリックのアラを読者に指摘されて、推理小説の
辻褄があうようにトリックを書き直そうと思えば小説全体を読み直して書き換える必要が
ある。それには相応の時間がかかるのは避けられないと思います。
>同様に「プログラマならemacsだろ!IDEなんか必要ない!」みたいな考え方の人もどうかと思います。
「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。
しょせんIDEなんて、単体のツールを集めただけの代物なんだから。
むしろ「IDEさえ使えればいい」、「単体のエディタなんて時代遅れだ」と思ってる人
の方がどうかと思います。そういう人はIDE付属の簡易エディタしか使ったことがなくて、
本物のエディタを理解していないんですね。酷い場合だと除き窓のような細いエディタ
領域の中から、横長で改行も入ってないようなコードを書いて平然としている人までいます。
機能単位で関数を分けると分散して読みにくくなると文句を言う人もいます。
あとJavaのように強力な型付けの言語で、それをIDEが解析して利用している場合なら
まだしも、Rubyのように動的な片付けの言語や、PHPのようにぐ支離滅裂な言語だと、
IDEの単体エディタに対する利点はかなり減るでしょうね。
Re: (スコア:0)
>内容の細部なんて忘れてしまいます。まして自分が当時気付かなかったミスについて
>修整を頼まれたんだから、自分が当時正しいと思っていた仮定なんてあてになりません。
プログラマが「時間が経っているので」って言っているので、
自分が書いたプログラムの理解に時間がかかるってことでは?
>あとJavaのように強力な型付けの言語で、それをIDEが解析して利用している場合なら
>まだしも、Rubyのように動的な片付けの言語や、PHPのようにぐ支離滅裂な言語
Re: (スコア:0)
> スクリプト言語でも、IDEを使うとプログラムの処理をブレイクポイントで止めたり
> その時点の変数の中身を見たりってことが簡単にできるので有益だと思います。
やり玉に挙げられていたEmacsでもできますけど。
むしろIDEなんてなかった時代からEmacsではできてました。
Re: (スコア:0)
あー、またですか [srad.jp]
どっちもどっちなような
emacs にしても大昔は重すぎだ巨艦大砲主義だと
今の IDE みたいな扱いをされてたわけで
#複数立ちあげてると叱られましたよ
Re: (スコア:0)
IDEを毛嫌いする人がIDEの機能を知りもしないってのはたしかにその通りだが、多くのIDEがGUIに依存している以上それはしかたないことなんだよな。GUIの利点は「できることが画面にすべて表示されている」ことなのに、IDEのように複雑な機能を持つソフトウェアにおいては「できることがさっぱり画面に表示されていない」という結果にしかもたらしてくれない。
その点コマンドラインベースの単体ツーツなら、mac coってやればcoコマンドでチェックアウト時にどのような特殊な機能を付加できるかは一目瞭然なわけで、学習曲線的にはむしろそっちのがはるかに効果的だ。
# まあそういう意味ではemacsのウンコっぷりはIDEと大差ないけど。
## 別にman coって書きたかったわけじゃないんだからね。勘違いしないでよね。
Re:あんまし関係がないと思う (スコア:1)
わかります。EmacsというIDEを使っておきながら、IDEなんか必要ないというのはおかしいですよね。
# わかってないけどIDで。
Re: (スコア:0)
任意の点がある三角形の内部にあるか外部にあるか判定する
モジュールを、プログラムするとするじゃん。
これ実際に某プロジェクトで最近作ったんだけどさ。
こんなの、コメントが無いと絶対他人には理解できない
プログラムになっちゃうんだよね。
いや、オレの実力が無いとか言われたらそれまでだけど。
コメント書いても、数学の知識が無いとかなり難しい。
知識があると簡単なんだけどね、実は単なる直線交差チェックだから。
「自称」達人プログラマもさ、
自分と同じ数学やプログラムの知識が無い人間がプログラムを読んだときに、
処理内容がわかるプログラムを書いているなら、自称が取れると思う。
が、コメント無しで上記アルゴリズムを実装してもらえるなら、
ちょっと見てみたいもんだ。
Re: (スコア:0)
> ちょっと見てみたいもんだ。
boolean Point.onSurface(Triangle triangle); // 直線交差チェックによる (山本山太郎「入門CG」153ページなど参照のこと)
くらいでいいんじゃないの?
なんにせよアルゴリズムに逐一コメントする必要はないし、するべきではないと思うよ。
化学の公式の人もそうだよね。
Re:あんまし関係がないと思う (スコア:1)
三角形内点判定になんで直線交差チェックが要るんだ?
外積符号判定じゃないのか?
the.ACount
Re: (スコア:0)
処理をコメントに書くから変なのでは?
コメントに
// 交差判定し、~の場合に~する
と書けばよいこと。細かい実装(アルゴリズム)の勉強はコメントを
見れば「そうか、交差判定の方法を調べればいいんだな」となります。
これが「交差判定」の語がなければ、知らない人は脳内ステップ実行して
動作から目的を導出しなくてはならず、解読不可能でしょう。
Re: (スコア:0)
> 自分と同じ数学やプログラムの知識が無い人間がプログラムを読んだときに、
> 処理内容がわかるプログラムを書いているなら、自称が取れると思う。
この辺、永遠のテーマですね。
「プログラムの知識が無い人間」って、要するに全人類だろってことになっちゃいますし。
Re: (スコア:0)
ケースバイケースですが、これはちょっと断定しちゃうのは反対。
修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
Re:あんまし関係がないと思う (スコア:2)
>> あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
>> バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
>ケースバイケースですが、これはちょっと断定しちゃうのは反対。
>修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
十数年前だったら、それも一利あったかもしれない。
当時でも否定する意見は多かったけど。
今だとこれはバージョン管理システム&バグトラッキングシステムで行うべきもの。
未だにそれを導入してない/導入したけど使ってないというのは、バカがすること。
「日本ではバカが非常に多い」という点については、残念ながらその通りというほかない。
Re:あんまし関係がないと思う (スコア:1, すばらしい洞察)
外れ。
外国だともっと進んでいるんだぜ、と思っているなら世の中を知らない。
また、外国も同様だという位知ってるというなら、わざわざ日本と前置きする意味が無い。
したがってその考えは「馬鹿と言うのは馬鹿」に当たっていないか?自問自答すべきだろう。
拡大解釈好きは、自分の論調に溺れがちだ。
Re: (スコア:0)
Re: (スコア:0)
>
>外れ。
>外国だともっと進んでいるんだぜ、と思っているなら世の中を知らない。
深読みしすぎてナナメ上の議論しちゃう人って多いですよね~。
自らがガイコクにコンプレックス持っているの丸わかりです。
元ACではないが「外国はスゴイ」ってどこに書いてあるの?ね?ね?
Re: (スコア:0)
いくらなんでもカコワルイ…
Re:あんまし関係がないと思う (スコア:1)
# 消したあとのソースでテストしないのって?いや、やりますよ。
# そのときはさくっと流して初回テスト時と同じ結果かDiffだけど。
まー、今時はバージョン管理ソフト使ってるところも多いからここまでやらんでもいいとは思うんですが、やり方をがらっと変えてバグ作り込むよりはいいかなって感じです。やってるときは前のコードも見てたいしw
Re:あんまし関係がないと思う (スコア:2)
過去のバージョンとdiffとってみて。
たぶんエライコトなってるから。
ファイルのコピー残しとけば良いんじゃ...
Re: (スコア:0)
SubversionやTracなりのバージョン管理なりバグ管理なりのシステムを導入して管理しろってことでしょ?
いまどきソースを日付フォルダやzipで管理してるなら、その時点で微妙だし。
# で、たまに古いやり方になれた人がやってきて、規約に残すなと書いてあるのにコメントアウトして残してたりする。
# 差分なんてツールで漏れなく正確に判るんだって!
Re: (スコア:0)
>差分なんてツールで漏れなく正確に判るんだって!
技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。
それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
Re:あんまし関係がないと思う (スコア:2, 興味深い)
> それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
> ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
ツールを使いたくないのであればプログラマーとかIT業界にいないで転職した方が良いと思います。
IT業界で「ツールを知らない」「ツールを使えない」「ツールを使おうという意欲がない」というのは
ある意味決定的な問題です。自分にとっても周りにとっても。
対人恐怖症の人がカウンセラーやっているのと同じぐらい悲劇です。
IT業界人は前向きにメンドクサガリでないと:-)
> そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
> あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
それはツールと関係ないのでは?
気持はお察ししますが。
Re:あんまし関係がないと思う (スコア:1, すばらしい洞察)
ある意味決定的な問題です。自分にとっても周りにとっても。
宗教家が原理論争やっているのと同じぐらい悲劇です。
#ネタですと言いきれない地獄
Re:あんまし関係がないと思う (スコア:1)
そういう場合はツールを使わなくても結局同じような悲劇が起こるので安心してください。
#宗教論争をするのは「神様を信じる人」であって、神様自身は論争しない
うじゃうじゃ
Re:あんまし関係がないと思う (スコア:1, おもしろおかしい)
んですがどうしましょう。
Re:あんまし関係がないと思う (スコア:1)
Re:あんまし関係がないと思う (スコア:1, 興味深い)
理由としては安全を確かめてからじゃないと許可できないそうで、使いたいならまず使用申請を出せとのこと。
その割に安全確認のプロセスが不透明で、いつ終わるのかの見積りすら出してこないので、結局申請する人は少ないようです。
しかも私のような外部参画者は申請することすら出来ない場合もあります。
あのエディタのあの機能なら10秒で終わるであろう仕事に、半日の工数を積めるので、こちらとしても文句はありませんが。
Re:あんまし関係がないと思う (スコア:1)
> ツールを使いたくないのであればプログラマーとかIT業界にいないで転職した方が良いと思います。
少し違うかも。
有用なツールを使って生産性を上げる、この指向なり志向なりは大切ですが、その生産性の向上が局所的な場合もあるのでは、と思いますね。
元の話は修正前の元コードをコメントアウトして残すや、バグ票番号を修正位置に残すのが是か非か、ですよね。非の方の意見は、diffやVCSやBTSを使えばその様なものをソースコードに残す必要は無い、だと思います。
元コードをコメントアウトはどうかと思います。が、例えば改修コードをトレースして確認する場合、そのトレースツール(シンボリックデバッガとか)が連携しているのはソースコードであってdiffやVCSやBTSでは無いでしょう。となれば、diffやVCS/BTSログ(ログに位置が記してあれば、ですが)のプリントアウトとかが必要となって、紙の無駄ではないかと。
やはり一概にugryとは言えないと思いますが。
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
えー・・・ネタだよね? 一応突っ込んどくけど、
「共有フォルダに最新ソースがあります。修正前後の差分はコメントを見れば判ります。」
と言われて引き継いだら、src_20091117 と src_最新版 と src_最新 フォルダがあったらどうしますか?
ついでに、コメントは基本的に適当デタラメだったらどうしますか?
バージョン管理システムやバグ管理システムは、作成者が更新しますが、最終的に管理者が管理するものですよ。
管理者の人が管理しなかったら、作成者にしかわからない状態になりますが、それは自業自得ですね。
# ちなみに全部実話です(涙
Re: (スコア:0)
言いたいことは判らなくもないけど、バージョン管理システム導入してても適切に運用されてなければ似たようなことは起こります。好き放題ブランチ切られた挙げ句収集がつかなくなるとか。
↑で書かれてることは「ルールが規定されてないor遵守されてない」ことに起因する問題なので、ソースの可読性云々とは少しブレてるんですよね。
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
・diffを使うのはずるい
・それは実力ではない
・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
・ツールを使うのはズルとしているのを同じ
ということでしょうか [okwave.jp]
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)
やだ、何言ってるのこの人・・・。
正気とは思えないんですけど。
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文とかでコメントアウト部分と
ソース部分が入り乱れているのをみて「なんとかなる」とか言い放ちやがって、あの○○野郎!
…と一時期本気で喧嘩売ろうかとおもったが、うちの部署はすっかり
ツールが整備されたので今は不満がない
Re: (スコア:0)
9割が変更履歴のソースコードを読みたいんですか?
システム化したほうがいいところはシステム化するのがシステム屋の仕事じゃないですか。
Re: (スコア:0)
ツールの導入時に先頭に立っていた者は、そのツールにトラブルが発生すると最後尾に回る
Re: (スコア:0)
色々突っ込みたいが一言でまとめるなら、
>検証をするのに残すべき
それで「検証」になると思うとは御目出度いね…ってとこです。
#まあ某ITゼネコンはそれを検証と呼ぶに値すると本気で思っているようだけども。
Re: (スコア:0)
Codeを書かないという技を会得した
Re: (スコア:0)