0001仕様書無しさん2013/06/04(火) 22:43:46.92
そういやデスマを乗り越えたソースのコメントに
おっぱいと書かれてた
よく考えたら、なんでコードとコメントを並行してメンテしなきゃならないんだ
本質的におんなじ内容のはずだろ
ということで俺は提唱するね
コンパイルできるコメント
あるいはコンパイルできる仕様書
ぴゅう太の日本語プログラミングの進化版と言ってもいい
このアイディアで特許とか製品とか早い者勝ちだぞ
ただし謝辞には必ず仕様書無しさんを入れろ
これ約束
変化の少ない情報なら、コメントでも良いけど、
仕様に関係あるものはアノテーションを使った方が良い。
あほか、
もちろん、JavaDocの様な仕様記述を行うのも重要だが、
コメントは意図や経緯を記述するとこであって、
ソースの動作を逐一説明するところじゃねぇぞ。
何故そうしたかはコードで表現できないからコメントするべきだけど
何をしたかはコードを読めばわかるから、コメントで二重に管理は無駄
説明コメントを一切書くなとまでは言わないけど、説明をしないと読み解きづらいコードは書くなっていつも思う
0829仕様書無しさん2014/03/13(木) 02:29:57.20
サブなら引数と戻り値が何なのかくらいだわ
0832仕様書無しさん2014/03/14(金) 16:09:30.83
小池きゅん
とにかくシンプルに書く
簡単であるほどよいプログラムと知れ
関数名、戻り値、引数だけでその関数の中身を見る必要がないようにしてください。
最初からできるものではないので、きっとコメントを書くでしょう。
そのときは自分は未熟だと思いながら書いてください。
コメントがなくなるころには、もうプロです。
がんばってください。
コメント書かない奴はクズ
コメント書けない奴はクズ未満
doxygen通したらすぐにAPIリファレンスができるコメント書けてやっと人並み
/* エラーメッセージを返す関数です */
getEroMassage()
コメントについて書いてあったので質問します
以前、条件分岐を書こうと思って、よく考えてみると
計算式で出来そうだったのでそうしたんですが
可読性に難ありなコードになってしまいました
条件分岐にしておけばだれでも分かりそうなコード
で済んだんですが
こういう場合は一般的に、詳細なコメント入れるのが
正解か条件分岐を使うのが正解か教えて下さい
計算式というのは三項演算子のことだと思うのですが、
それであれば正解はないと思います。
言語によって良い悪いがあったり好みの部分も強いお話なためです。
とはいえ、可読性に難がある状態になってしまった時点で
きっと何かがおかしいのだと思います。
何かというのは843さんのコードかもしれませんし、
843さんが手を加える前のコードやDB設計がおかしくて、
どのようにコードを書いてもわかりにくくなってしまうようなものだった、
のかもしれません。
難あり、と思ったらコメント書けばいい
3カ月も経ったら自分でも読めなくなりそうだし
いやあるって
3カ月もあれば他のソース何十本も触るから
他人が書いたソースと変わらなくなるよ
3ヶ月は大袈裟でも1年経ったら当時の意図が読めなくなることはある
0852仕様書無しさん2016/05/03(火) 15:14:17.91
俺もないと思う。
10年経っても、自分で作ったソースの内容は覚えてる。
いや、土日挟むともう先週書いたコードの内容なんか忘れてるから。
何年も前のコード思い出せるのは、ずっと同じPJで仕事してる豚だな
1ヵ月前はこっちのバッチプログラム、3ヵ月前はあっちの金融系、6ヵ月前はそっちのWindowsアプリなんて生活してる奴は事情が違ってくる
火消し屋の評価の低さにうんざりして転職したからなんとも言えんな。
0861仕様書無しさん2016/10/09(日) 16:55:04.12
git add
git commit
する癖