「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（補足編） - 土屋つかさの技術ブログは今か無しか

前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（ http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 ）」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案１：マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理Ａ } "1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑

[t_tutiya]

ブログの方にコメントを頂いて気づいたんですが、isFadeinCompletedではなくisFadeinRunningでないとダメ（あるいは条件式の符号を反転すべき）でしたね。不完全な記事を書いてしまい申し訳ありません＞＜

[nyagoking]

丁寧なコード書こうが、別途コメントで記載しようが、アンポンタンにメンテされたら終いなんだよなぁ…。コメント無しより嘘コメントの方がタチ悪いので、自分ならコメント無しで丁寧に書く方を選ぶけど…

[love0hate]

ここまでの話、全部リーダブルコードに書いてあるんでまずは読んでくださいとしか。

[rti7743]

コメントを書くとしたら、なぜそのif文が必要なのか？なぜ分岐しないといけないのか？っていうのを説明するコメントを書くんでね。なぜ？はソースコードでは表現しにくいだろうし。

[cpw]

この記事には賛同しかねるなー。id:erukitiの書き方の方が明快。コメントはいろいろな理由で素直に実装していない箇所と難解な箇所にだけ使えばいいと思ってる。

[htnmiki]

WhatでなくWhyを書けと何度言ったら

[vanbraam]

大幅に主張が後退した."幻想"->"実務で書く時は〜".実務云々は何ら論理的な理由の説明になってないし,名前空間汚染もprivateメソッドで終わる話;仕様書とコメントというconcernの粒度が違い過ぎる物を一緒に論じるのも乱暴

[td2sk]

ソースコードからすぐには読み取れないような高次元のロジック、設計判断が書いてあってほしい

[kagerou_ts]

ここまでがんばってコメント避けるよか素直にコメントつけていきたい。そして結局コメント入れるのが一番わかりやすい。コードの実装意図や解説をコメントしていくのは有用だと思ってる。

[strawberryhunter]

プログラマーはやせ我慢が好きだな。コメントを書かないとか、わかりもしないのに変な英語を使ったり。プログラミング言語の設計者がコメントの書式を用意している以上、コメントは必要だと考えられているんだろう。

[OkadaHiroshi]

id:erukiti の const isFadeinCompleted = () => alpha < 1.0 と書くのは、この定義を宣言の有効範囲外に出るまで覚えていなくてはならない、頭のスタックを余計に消費するのは避けたい。関数化するかは行数でなく抽象化できるかだ。

[FTTH]

俺がポルポトで「プログラマーを根絶したい」と思ったらコーディングスタイルについて適当な議論を書き飛ばせばいいんだな、という気付きを得ましたが使用する局面がない

[Error401]

『リーダブルコード』曰く、「ぼくたちからのアドバイスはこうだ。「コードを理解するのに役立つものなら何でもいい から書こう」これなら、WHATでもHOWでもWHYでも（あるいは3つ全部でも）書 ける。」

[SatoshiN21]

whyが伝わればなんでもいい。コードで全てが理解可能なのが理想だが、whyが伝えらていないのにもかかわらず何もコメント付いてなかったら書けと言いたい

[su_zu_ki_1010]

プログラムの内容にもよるけど、頑張ってメソッド名で表現するだけの英語能力もないので素直にコメントで書いておいた方がいいと思うのです。

[melanmer]

http://archive.is/oIrU3

[mandel59]

「「１行の式を返すだけの処理をメソッド化しない」というルールがある」

[otihateten3510]

案2でいいのでは？　俺は案2にした上でコメントも書くよ。自分自身含め、誰も信じてないから。　案2+コメントにすると誤った改編がほぼできなくなるし問題の切り分けがし易い。

[umai_bow]

両方書けばいいだろ

[cartman0]

個人的にはjupyter notebookが理想で、詳細なコメントをmarkdownと階層的に書きたいのよね

[munegon]

未完了をCompletedにしてる時点で何もかもダメだと思う

[akabekobeko]

「インターフェース」に対して「目的と意図」を書く。コード修正で「目的と意図」が変わることは稀だから同期の問題は起きにくい。API リファレンスのつもりで書けば自然とこんな感じになるのでは。

[trini]

何年か前に自分で書いたソースを数年ぶりに見たら、何やってるか分からないのでコメントは未来の自分のために必要w

[Magicant]

皆さんいろいろ思ふところはあるんだらうけど、土屋さんがなぜ「コード=ドキュメント」は無理筋と思ってるのか分からないと話は進まなさう。

[snowlong]

プログラムの話なのに説明が全然論理的じゃなくて笑う

[happo31]

目的はコードの意図が相手に伝わるかどうかなのでコメント書こうが書くまいがそこはどうでもいい

[kwhrtsk]

コメントが不要とまでは思わないが「１行の式を返すだけの処理をメソッド化しない」この縛りは「不要な」コメントを増やして可読性を落とすだけだからやめた方がいい。

[turanukimaru]

数学は人間の意図を超えて抽象化された存在であるからこそ万事に使うことができる。つまり、数学的には正しいが意図を失う瞬間と言うものが必ずある。そこではコメントは必要なのではないか。

[tzt]

言語や文脈にもよるけど自分ならアルファ値をいい感じの名前のValueObjectにしてメソッド生やすかなあ。

[ghostbass]

コードコンプリートでは抽象化レベルをそろえるための関数を使ってましたね。つまりisFadeinCompleted(){}みたいな。

[ono_matope]

自分もレガシーコードのリファクタリング過程でもなければ、一度しか使われない一行コードの定義は避けるな。メソッドに聞いて終わる単純な条件ばかりでもないし。使ってる言語でも傾向は違うと思うけど。