ファイルの冒頭コメントにはこのようなもの書け！
■ このスレッドは過去ログ倉庫に格納されています
最も大切なのは、ソースファイルや設定ファイルなどの冒頭に、
動作に差し支えのない範囲でコメントを残すことだ。
そこに、次の情報を含める。
・ このファイルの名前
・ このファイルの概要（何をするものかを簡潔に）
・ 最終編集時に施した修正内容
・ 最終編集者（最終編集者以外は書かない）
・ 最終編集日（最終編集日以外は書かない）
■ソースファイルなどの冒頭に記すべきコメントの例
#######################################
#
# プログラムや設定ファイルの名
# そのプログラムの概要
#
# その他のコメント……
# ・このリビジョンで何をしたのか
#
# Written by 最終編集者on 最終編集日
#
#######################################
プログラムの途中にコメントを残すのもよいが、冒頭にも残す。
途中に書いてあるだけでは、書いてある場所を探すのが手間だ。
また、最終編集した際の日付と人（メールアドレスなど）も記す。
長年経った時に、そのリビジョンをいつ誰が作成したのか把握するためだ。それが他人であった場合、
わからないことがあればその者に聞けばいい。だたし、複数人で手を入れていたとして、
最終編集者でない者の名前や日付を残す必要はないし、むしろ消すべきだ。
歴代の担当者が知りたくば、リポジトリーに残っている過去のリビジョンを見れば済む。
同様の理由で、修正前のコードをコメントアウトした状態で残す悪習も止めること。 >>30
だからね。それはバージョン管理じゃないの。ただのリリース作業
バージョンとバージョンの間の、ソースコードの一連の修正（たくさんのコミット）を
記録できないものはバージョン管理じゃないの 有名なオープンソースソフトウェアでもこういうコメントがガリガリ書いてあったりする。 >>35
理由を検討したいので教えて
たぶん単に古いコードが残ってるとか
著作権情報と勘違いしてるだけでしょ？ >>36
共同作業だと、そのファイルそのものに書いてあった方がうまくいくことが多い。 もうコメントなんて見る人が分かりやすければ気にする必要は皆無 コメントが書けないようなレベルのプログラマが多いということだ。 >>38
質問したのはどのオープンソースプロジェクトかって話ね
ないよね？共同作業だとそんな事したら
最後にタイポの修正した人が編集者になるからねｗ >>40
ユニケージの人たちって、
コメントにコードの意味を書いてるから
馬鹿な人達だなぁって思ってるｗ
自分が書いたコードの意味がわからないんだよね
コメントはコードに書いてないものを書くのにね。 そういやユニケージは
サクラエディタが推奨エディタらしいねｗ >>46
VSCodeは日本語のキャラクタセットがまだまだ苦手だからな。 プラグイン？どちらにしろ誰かにあてがってもらわないと
使えないなら無能なことに変わりない 日本語みたいなマイナー言語は無視という流れだからな。 Linux システムは、BOM 無しUTF-8 のみ
世界中で、CP932/sjis を使っているのは、5ch だけw 今どきSJISとかEUC-JPとかを使わなきゃいけない状況で仕事するのは、純粋に辛そう。
もちろん組込とかでそういう縛りのある分野もあるのはわかるけど、Unicodeじゃないなんて辛すぎる。 >>59
EOSで新環境に移行するけど古ーーーいプログラムがEUC-JPです←まあわかる
変換面倒なので新環境もEUC-JPで構築します←えっっっっ
なことがあったわ >>58
Windowsは多言語対応
SJISはおまえのための設定 UTF-16の2バイト1文字ですべて収まると思われていた時代に普及してしまったから仕方ない。 多言語であることと
多CPであることは
関係ないぞ だからファイル名やディレクトリ名は単純な７ビット文字で書けって
日本語はまだいいほうでヨーロッパ文字で書かれると見分けがつかないし変な重複ファイルになっておかしなバグの原因になる >>63
なぜUnicodeという名前なのか考えたことがあるのか？ Unicodeの「Uni」は当初は一文字を16ビットで揃えるという考えだったが、16ビットでは不可能とわかって、Unicodeの定義が変わった。 まあ気持ちはわかる
経験少ないエンジニアは後任や自身があとでメンテするのに必要なコメント書かないからな
一番笑ったのはスピード自慢のpgがコメント全く書かずに自分でもどこで何やったか全くわからなくなってバグ解析お手上げになった案件w
焦ってgitの履歴とにらめっこしてるの見て更に爆笑w バカにされてるのはコメント書かないことじゃなくて、
自分が書いたコードの意味を日本語で説明しなきゃならんのかってところなんだよな
あとバージョン管理されてる情報はコメントで書く必要ない >>67
gitの履歴にらめっこできるのは良いポイントだよね
同じ状況になった時、git管理してないとお手上げになる >>69
git履歴もなんにもコメント残してなかったから結局お手上げ
時間のムダたった
その後はPLの俺が根気よく読み解いて全体の半分は書き直したよ
自分のコードも読めない自惚れPGにはまず要所要所にコメントを書くことを学んでほしい
俺は案件さすらいのPM/PLだからそいつがその後成長できたかはしらんけど
よくまああれでフリーランス何年もやっとるなと驚いたもんだ コメントではなくてドキュメント
つまり設計書とかまったくなしでやるのかい? バージョン管理ツールの履歴があるからいいんだというやつは、間違いなく履歴を調べて元の仕様を確認したことがないやつ。
履歴が残っていても、それがどういう状態のものなのかわからないと意味がない。 >>70
それとgitを使うこととは関係ないよねｗ >>72
はいはい。コメントあっても無駄なコメントありますね
i++ // 一増やす
とかさぁｗｗｗ 要件定義書、基本設計書、仕様書（詳細設計書）、gitコメント、ソースコメントそれぞれ書くべきことがある
区別できないのはアマチュア >>74
入門書に書いてあるコメントを書くのがコメントだと勘違いしているプログラマは多い。 >>1
∧__∧
( ･ω･) いやどす
ﾊ∨/^ヽ
ﾉ::[三ﾉ :.､
i)､_;|*く; ﾉ
|!: ::.".T~
ﾊ､___|
"""~""""""~"""~"""~" そのプログラムを一番早く確実に解読するために必要な情報をコメントするんだったら、別にルールに縛られずに好きに書いてもいいだろ？
初心者マークの付いたようなコメントでも必要とされる場合もある。初心者レベルのコメントが不要と笑う者は、そんなコメント無視できるくらいの器を持てよ。
自分はVHDLのプログラムを初めて書いたときに文法もよく分からなかったから教科書に載っているような内容も細かく書いてたけど、随分役に立ったし、他の人が見ても分かりやすいと評判だったよ。なにより、他の初心者が参考にしてくれてみんなスキルが上がっていったのが1番良かった。
上級者が読んでも、うん、理解して書いてるな、と安心して貰えたらしい。 漠∞！！！！
斗∞！！！！！
及∞！！！！！！
山∞！！！！！！！ ■ このスレッドは過去ログ倉庫に格納されています
