関数型プログラミングを始めたばかりで、コードをコメントする正しい方法について疑問に思っています。
名前と署名はすでにあなたが知る必要があるすべてをあなたに伝えるはずなので、短い関数をコメントすることは少し冗長に思えます。大きな関数は一般的に小さな自己記述関数で構成されているため、大きな関数のコメントも少し冗長に見えます。
機能的なプログラムにコメントする正しい方法は何ですか?反復プログラミングと同じアプローチを使用する必要がありますか?
関数型プログラミングを始めたばかりで、コードをコメントする正しい方法について疑問に思っています。
名前と署名はすでにあなたが知る必要があるすべてをあなたに伝えるはずなので、短い関数をコメントすることは少し冗長に思えます。大きな関数は一般的に小さな自己記述関数で構成されているため、大きな関数のコメントも少し冗長に見えます。
機能的なプログラムにコメントする正しい方法は何ですか?反復プログラミングと同じアプローチを使用する必要がありますか?
回答:
関数名はあなたが何をしているのかを言うべきです。
実装により、どのように実行されているかがわかります。
コメントを使用して、その理由を説明してください。
関数型プログラムは通常、命令型プログラムとは異なる抽象化レベルにあるため、この質問には間違いなくポイントがあります。
このため、別のスタイルのドキュメントが必要です。反復プログラムでは、次のコードのようにコメントが役立つ場合があります。コードの本質は定型句の後ろに隠れているためです。
// 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
関数を文書化する理由は、読者が関数の本体を読みたくない、または読むことができないからです。このため、関数型言語であっても大きな関数を文書化する必要があります。関数の実装を見ることで関数が何をするのかを理解しやすいかどうかは関係ありません。
関数名とパラメーター名だけでは指定できない場合は、関数をコメント化する必要があります コントラクト。
// returns a list of Employees <-- not necessary
def GetEmployeeList: ...
// returns a list of Employees sorted by last name <-- necessary
def GetEmployeeList: ...
一言で言えば、コントラクトは関数が期待するものとそれが保証するものを定義します。厳密に言えば、GetEmployeeList
ソートされたリストを返すが、関数名またはコメントのいずれかでそう言っていない場合、この関数のコンシューマーはこの動作に依存してはなりません。文書化されていない実装の詳細であり、作成者はGetEmployeeList
この動作をいつでも変更できます。
私はすべてのコードを文書化するために同じアプローチを取ります。
名前と型の署名が関数の機能を正確に示していない場合、通常は間違っています。
25歳では、物事をずっとよく覚える傾向があります。年を取り、レガシーコードを使用する複数のシステムに関与している場合(そう、今日記述するコードは10〜15年でレガシーコードになります)、コメントがあると非常に役立ちます。