アカウント名:
パスワード:
> 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば> 「美しい」コードだったりします。
内容は賛成ですが、万人にはお勧めできないと思います。「自称」やり手プログラマの中には、コメントがなければ美しいコードだと勘違いしている人がいるようなので。
以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、「コメントがなくてもわかりやすく書いてある」と言っていたのですが、そのソースコードの不具合改修をお願いすると「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」と言ってました。そのためのコメントじゃないの？
同様に「プログラマならemacsだろ！IDEなんか必要ない！」みたいな考え方の人もどうかと思います。
> そのためのコメントじゃないの？
コメントが書かれているからといってプログラムを解析する手間がなくなるわけじゃない。
だってコメントが書いてあってもそれが正しいという保証はない。
だから必ずコメントとコードが整合しているかチェックしなくちゃいけないけど、これがコードを直接、解析するより楽かどうかはコメント(とコード)の品質による。
「優れたコメントは優れたコードと同じくらいプログラムにとって重要だ」
という言葉を聞いたことがある。(ストールマンがいってたような…)
しかし私は言おう。
「劣悪なコメントは凶悪なバグと同じくらいプログラムにとって有害だ」
と
> コメントとコードが整合しているかそれはコメントでコーディングしているだけで、そんなチェックをしなければならないようなことがコメントに書かれている時点でコメントの使い方を間違えてる。言語仕様が貧弱なので仕方なくコメントで事前条件を書いているということはあるかもしれないけど。
＞「自称」やり手プログラマの中には、＞コメントがなければ美しいコードだと勘違いしている人がいるようなので。こっちの指摘はまあまあ理解できるけど、
＞そのためのコメントじゃないの？それは必ずしも正しくないと思う。コメントがあった方が良い局面というのはあるけれど、コメントがあればデバッグのためのソースの解析が不要になるかというとそんなことはない。
たとえ自分が書いたプログラムやコメントでも、書いてから何年もたてば自分が書いた内容の細部なんて忘れてしまいます。まして自分が当時気付かなかったミスについて修整を頼まれたんだから、自分が当時正しいと思っていた仮定なんてあてになりません。
例えば，自分で書いた推理小説の密室トリックのアラを読者に指摘されて、推理小説の辻褄があうようにトリックを書き直そうと思えば小説全体を読み直して書き換える必要がある。それには相応の時間がかかるのは避けられないと思います。
＞同様に「プログラマならemacsだろ！IDEなんか必要ない！」みたいな考え方の人もどうかと思います。
「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。しょせんIDEなんて、単体のツールを集めただけの代物なんだから。
むしろ「IDEさえ使えればいい」、「単体のエディタなんて時代遅れだ」と思ってる人の方がどうかと思います。そういう人はIDE付属の簡易エディタしか使ったことがなくて、本物のエディタを理解していないんですね。酷い場合だと除き窓のような細いエディタ領域の中から、横長で改行も入ってないようなコードを書いて平然としている人までいます。機能単位で関数を分けると分散して読みにくくなると文句を言う人もいます。
あとJavaのように強力な型付けの言語で、それをIDEが解析して利用している場合ならまだしも、Rubyのように動的な片付けの言語や、PHPのようにぐ支離滅裂な言語だと、IDEの単体エディタに対する利点はかなり減るでしょうね。
> スクリプト言語でも、IDEを使うとプログラムの処理をブレイクポイントで止めたり> その時点の変数の中身を見たりってことが簡単にできるので有益だと思います。
やり玉に挙げられていたEmacsでもできますけど。むしろIDEなんてなかった時代からEmacsではできてました。
あー、またですか [srad.jp]どっちもどっちなような
emacs にしても大昔は重すぎだ巨艦大砲主義だと今の IDE みたいな扱いをされてたわけで#複数立ちあげてると叱られましたよ
>「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。
説明の仕方が悪い(ので理解してもらえない)んだよ。
この場合は、「EmacsはIDEです」のひとことで十分だ。
＃あれが単体エディタだというなら、なぜモバギのPocketBSDでEmacsを起動するのに何十秒もかかるんだ？
三角形内点判定になんで直線交差チェックが要るんだ？外積符号判定じゃないのか？
処理をコメントに書くから変なのでは？コメントに
// 交差判定し、～の場合に～する
と書けばよいこと。細かい実装（アルゴリズム）の勉強はコメントを見れば「そうか、交差判定の方法を調べればいいんだな」となります。これが「交差判定」の語がなければ、知らない人は脳内ステップ実行して動作から目的を導出しなくてはならず、解読不可能でしょう。
> 自分と同じ数学やプログラムの知識が無い人間がプログラムを読んだときに、> 処理内容がわかるプログラムを書いているなら、自称が取れると思う。この辺、永遠のテーマですね。
「プログラムの知識が無い人間」って、要するに全人類だろってことになっちゃいますし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
あんまし関係がないと思う (スコア:4, すばらしい洞察)
文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
「美しい」コードだったりします。
むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。
コメントもコードも「言語」ですからね。
#ってか、「非プログラマ」な人種はソースなんて見るのか？(＜俺)
---- ばくさん！＠一応IT土方
Re:あんまし関係がないと思う (スコア:4, すばらしい洞察)
> 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
> 「美しい」コードだったりします。
内容は賛成ですが、万人にはお勧めできないと思います。
「自称」やり手プログラマの中には、
コメントがなければ美しいコードだと勘違いしている人がいるようなので。
以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、
「コメントがなくてもわかりやすく書いてある」
と言っていたのですが、そのソースコードの不具合改修をお願いすると
「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」
と言ってました。
そのためのコメントじゃないの？
同様に「プログラマならemacsだろ！IDEなんか必要ない！」みたいな考え方の人もどうかと思います。
Re:あんまし関係がないと思う (スコア:2)
> そのためのコメントじゃないの？
コメントが書かれているからといってプログラムを
解析する手間がなくなるわけじゃない。
だってコメントが書いてあってもそれが正しいという
保証はない。
だから必ずコメントとコードが整合しているかチェックしなくちゃ
いけないけど、これがコードを直接、解析するより楽かどうかは
コメント(とコード)の品質による。
「優れたコメントは優れたコードと同じくらいプログラムにとって重要だ」
という言葉を聞いたことがある。(ストールマンがいってたような…)
しかし私は言おう。
「劣悪なコメントは凶悪なバグと同じくらいプログラムにとって有害だ」
と
Re: (スコア:0)
> コメントとコードが整合しているか
それはコメントでコーディングしているだけで、そんなチェックをしなければならないようなことがコメントに書かれている時点でコメントの使い方を間違えてる。
言語仕様が貧弱なので仕方なくコメントで事前条件を書いているということはあるかもしれないけど。
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: (スコア:0)
Re: (スコア:0)
emacsを毛嫌いする人がemacsの機能を知りもしないってのはたしかにその通りだが、多くのemacsがLISPに依存している以上それはしかたないことなんだよな。LISPの利点は「やりたいコードが簡単にすべて表現できる」ことなのに、emacsのように複雑な機能を持つソフトウェアにおいては「使いたい関数がどこにあるのかさっぱりわからない」という結果しかもたらしてくれない。
その点コマンドラインベースのviなら、:wqってやればwコマンドとqコマンドでファイルの保存時にどのような特殊な機能を付加できるかは一目瞭然なわけで、学習曲線的にはむしろそっちのがはるかに効果的だ。
# はっきり言って、的外れ。IDE信奉者もemacianも同類。vier はただの勘違い野郎だ。どこが一目瞭然なんだよ。
## 別にバカにしているわけじゃないんだからね。勘違いしないでよね。問題の観点がオカシイと言ってるだけです。
Re: (スコア:0)
>「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。
説明の仕方が悪い(ので理解してもらえない)んだよ。
この場合は、「EmacsはIDEです」のひとことで十分だ。
＃あれが単体エディタだというなら、なぜモバギのPocketBSDでEmacsを起動するのに何十秒もかかるんだ？
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)
> 自分と同じ数学やプログラムの知識が無い人間がプログラムを読んだときに、
> 処理内容がわかるプログラムを書いているなら、自称が取れると思う。
この辺、永遠のテーマですね。
「プログラムの知識が無い人間」って、要するに全人類だろってことになっちゃいますし。