関数型言語では異なるコメントが必要ですか?[閉まっている]


25

関数型プログラミングを始めたばかりで、コードをコメントする正しい方法について疑問に思っています。

名前と署名はすでにあなたが知る必要があるすべてをあなたに伝えるはずなので、短い関数をコメントすることは少し冗長に思えます。大きな関数は一般的に小さな自己記述関数で構成されているため、大きな関数のコメントも少し冗長に見えます。

機能的なプログラムにコメントする正しい方法は何ですか?反復プログラミングと同じアプローチを使用する必要がありますか?


7
「それらは一般的に小さな自己記述関数で構成されているためです。」—それは原則として、命令型言語でも違いはありません。それでも、大規模な関数が最終的に何をするのかがすぐにはわからないことがよくあります。コード自体から常に推測できますが、コメントを読むよりもかなり時間がかかる場合は、提供する必要があります。
leftaroundabout

2
同意しません。機能langagesは、あなたがそれを最後に行います正確に何を知っている副作用が与えられた署名を使用して値を返すいけないので
トム・スクワイアーズ

8
すべての関数型言語が純粋であるとは限らず、一部の言語には副作用があります。
サノスパパタナシオ

1
しかし、あなたがコメントしたいことをコメントしてください...これは
考え直し

1
プロジェクトには、関数型言語に精通していない他のメンバーがいるというリスクがありますか?彼らはいくつかの追加の助けが必要な場合があります。
ジェフ

回答:


84

関数名はあなたがをしているのを言うべきです。

実装により、どのように実行されているわかります。

コメントを使用して、その理由を説明てください。


1
すばらしい答えです。何がどのように(コード自体からも明らか)を説明するコメントが散らばっているコードを見ることはできませんが、その理由は推測できません。
エリックウィルソン

32
これは、パラダイムに関係なく当てはまります
jk。

2
これはおそらく言うまでもありませんが、コードが複雑または複雑であり、そのような説明が必要な場合は、どのような方法でコメントを追加する必要があります。もちろん、このようなコードもおそらく避けるべきですが、それは常に可能とは限りません。
user606723

3
この答えは非常に単純であり、単純さには多くの価値がありますが、完全に真実ではありません。関数名は多くの場合「何」を十分に詳細に記述できないため、文書化が必要になることがよくあります(例:エッジケースを記述するため)。ドキュメントは頻繁にコメントに挿入されます。
luiscubal

2
ほぼ間違いなく、関数名はそれがなぜそれをしているのか-可能な場合にはそれも説明すべきです。
ヤムマルコビッチ

14

関数型プログラムは通常、命令型プログラムとは異なる抽象化レベルにあるため、この質問に間違いなくポイントがあります。

このため、別のスタイルのドキュメントが必要です。反復プログラムでは、次のコードのようにコメントが役立つ場合があります。コードの本質は定型句の後ろに隠れているためです。

// map 'toUpperCase' over 'container' yielding 'result'
Container result = new Container();
for (int i=0; i < container.size(); i++) { 
             result.addToTail(container.atElement(i).toUpperCase());
}

しかし、これは関数型言語では明らかにナンセンスです。

-- map 'toUpperCase' over 'list'
let result = map toUpperCase list

より良い:

-- we need the FooBars in all uppercase for the Frobnitz-Interface
let result = map toUpperCase list

8
おじいちゃんはいつも、何の代わりに理由を文書化するように私に言います。したがって、命令型コードにも最後のバージョンを使用します。
サイモンベルゴット

3
おじいちゃんは正しい。それにもかかわらず、命令型の領域では意味のある特定のコメントは、機能では絶対に役に立たないことを示したかっただけです。
インゴ

11

関数を文書化する理由は、読者が関数の本体を読みたくない、または読むことができないからです。このため、関数型言語であっても大きな関数を文書化する必要があります。関数の実装を見ることで関数が何をするのかを理解しやすいかどうかは関係ありません。


良い点。特に、読者がコンパイルされたライブラリを使用していて、公開された関数シグネチャとそのコメントしか見ることができない場合。彼らはあなたのコードの自己記述的な内臓を見ることは決してないでしょう。
FrustratedWithFormsDesigner

3

関数名とパラメーター名だけでは指定できない場合は、関数をコメント化する必要があります コントラクト

// returns a list of Employees    <-- not necessary
def GetEmployeeList: ...

// returns a list of Employees sorted by last name    <-- necessary
def GetEmployeeList: ...

一言で言えば、コントラクトは関数が期待するものとそれが保証するものを定義します。厳密に言えば、GetEmployeeListソートされたリストを返すが、関数名またはコメントのいずれかでそう言っていない場合、この関数のコンシューマーはこの動作に依存してはなりません。文書化されていない実装の詳細であり、作成者はGetEmployeeListこの動作をいつでも変更できます。


2

コメント自体には、コードが行うことに対する代替の説明(実際にはコード自体によって表される)を含めるべきではなく、むしろ、理由の説明を必要があります。

そうは言っても、コメント自体が関数型言語で異なるべき理由はわかりません。


1

私はすべてのコードを文書化するために同じアプローチを取ります。

  • わかりやすい名前を使用し、
  • 複雑なロジックを回避できない場合は、合理的に複雑なロジックの前にコメントを追加します。
  • システム全体の概要を記述し、

名前と型の署名が関数の機能を正確に示していない場合、通常は間違っています。


0

25歳では、物事をずっとよく覚える傾向があります。年を取り、レガシーコードを使用する複数のシステムに関与している場合(そう、今日記述するコードは10〜15年でレガシーコードになります)、コメントがあると非常に役立ちます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.