質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

Q&A

解決済

5回答

411閲覧

プログラムのコードにコメントって書かなくても良いですか?

退会済みユーザー

退会済みユーザー

総合スコア0

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

0グッド

0クリップ

投稿2017/10/11 09:59

プログラムのコードにコメントが必要なケースって以下くらい、その他の場合は特にコメント書かなくても良いですか?

  • 可読性を犠牲にして計算処理を高めるような難解なアルゴリズム書いたりする時
  • TODO:やFIXME:的なコメントを残す必要がある時
  • 英語に弱い人が多いチームの場合(?)

ここで何やってますみたいなコードは、メソッド名や変数名見れば分かるので、いちいち説明しないで良いですよね?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答5

0

僕はコメントは絶対必要だと思っています。
そして、コメントに書くべき内容というのは、そのコードが「何を」しているかではなく、
なぜ」しているかということです。
何をしているかは、よほど難解でない限りコードを見れば分かります。
知りたいのは、なぜこのコードが必要なのかってとこです。

自分のコードだったとしても1ヶ月も経てば、何でこれが必要なんだったっけ?っとなるのは
プログラマーあるあるです。

Java

1// ユーザー情報を作成 2User user = new User(); 3// 作成したユーザーに必要な情報をセットしていく 4user.setId(id); 5user.setName(name);

こういうのはクソコメントですね。

投稿2017/10/11 11:06

root_jp

総合スコア4666

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

この辺はリーダブルコードを参照だね。
紹介されている内覚えているのは下記。

  • 複数選択肢の内、なぜこの選択肢を取ったのか
  • 勝手にリファクタリングすると大ハマリする可能性がある箇所

他にもWebStorm使っているエンジニアが居るなら、
JSDocを残しておくと補完がバシバシ効くから超絶感謝されるよ。

私はWebStorm使うエンジニア居ないから、Haskellの関数定義を見習った何かを記述するようにしてるね。
1行で簡素に書けるから関数名と合わせて簡単に使い方を思い出せて便利に感じてるよ。

JavaScript

1// isHoge :: String -> Boolean 2const isHoge = R.pipe(R.prop(a), b, R.allPass([c, d, e]))

他にはドキュメント化したりREADME.mdに残したり、
いろんな選択肢があるから、その都度考える感じかな。

投稿2017/10/11 10:42

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

処理についてはコードとして書いてあるのでコメントとして残す必要性はないと思いますが、そのコードには含まれないコンテキストについては残す方が良いと思います。

私の場合には良くインシデントやバグチケット、MSDNやその他リファレンス、StackoverflowやGitHubのURLと、なぜそこを参照すべきなのかという理由を書いてます。

綺麗なコードは何をやっているか自明ですが、なぜそうしたかというコンテキストは、整える過程でコードから削ぎ落とされているはずなので。

投稿2017/10/11 10:55

YouheiSakurai

総合スコア6142

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

YouheiSakurai

2017/10/11 10:56

あとHow to useもよくコメントとして残します。
YouheiSakurai

2017/10/11 10:57

あと見落としがちなコーナーケースも。
guest

0

個人的な考えを記載します。
いろいろな考え方があると思いますので、参考程度にしてもらえればと思います。

・自分以外の誰かが見る可能性があるのか
・誤解が生じると影響度が高い内容なのか
・IDEなどで呼び出されるメソッドの内容が見える必要はないのか

例えば、メソッドにコメントがないフレームワークを見たことはありますでしょうか。
動作することは最低条件ではありますが、フレームワークのコードは多くの人が見て同じ理解をして頂く必要があります。
多くの人が見るという前提であれば、スキル差があるためコメントを書くことで誤解なく伝えることが必要となります。
またIDEなどを使用していれば、コードを書く時にコメントが表示されてどのような処理が行われるメソッドなのかがすぐに分かることもあると思います。

ではフレームワークではなく、とある処理の一部からしか呼ばれないプライベートなメソッドには必要無いのでしょうか。
結論から書くと必要な場合のほうが多いと思います。
もし会社など組織でコードを書いている場合は、そのコードを書いた人は永久にそのコードを保守してくれる約束はされていません。
他の誰がそれを引き継ぎ、保守しなければなりません。
その時にそこに書かれているコードの意図や思いは、コードからは読み取れないケースがあります。
あるいは動作はするが、仕様とは違うことにより、期待する結果が返されないケースなどがあると、その人は現場のコードがなぜそのようなコードになっているのか というところから考えなければなりません。

以上のようなことは、今ではなく未来になってやっと分かることかもしれません。
もしコメントを書かなくても良いと思うのでしたら、自分のためではなく人のために書いてあげると良いかもしれません。
参考になれば、幸いです。

投稿2017/10/11 10:59

YasuhiroMiyake

総合スコア1336

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ベストアンサー

コメントは所詮コメントなので、「書かなくて良いか?」と聞かれれば「YES」としか
答えようがありません。
ただしプロジェクトで作業を行う限り、コメントについてもルールが設定されるはずです。
プロジェクトの方針にあわせて下さい。

投稿2017/10/11 10:20

yambejp

総合スコア114572

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問