>>529
オレが意図を誤解しているかもしれないが、その点については悩ましいと思っている。

抽象的な関数とは機能が多岐に分かれているマルチな関数であり、
具体的な関数とは関数の用途が一意に決まっている関数と考えさせてもらう。
仕様という言葉でインターフェイス(I/F)と言い表すと、
設計という言葉で表すべきはその関数の使い方だろう。

I/Fの抽象度が高いほど、関数の使い方は多岐に別れて
冗長するが、関数の数は減り1関数の処理を追うのが容易になる。
(もちろんグローバル変数やgetsetの乱立等するとさらに厄介だしメンテが困難だ)
この場合コメントに頼る面が多くなりがちだ。

onConnectInputAddの仕様(I/F)を入力のみの4つの引数が
何かと接続する処理とした時に、接続する最低条件とマッチしている、
またはこの関数の動くシステムで一般的であるならコメントは不要だが、
4つの引数が不明瞭・説明不足ならばそれは抽象的でも具体的でも無く、
仕様ミスと言える。

抽象度が高いI/Fとは、
例えばメンバの多い構造体や子孫の多い構造体ををI/Fにするような事、
引数の多い物(多すぎるのは考え物であるが)となり、時に仕様と設計の説明が必要になる。
抽象度が低い＝具体的な場合とはその逆とすると、仕様と設計の説明が不要になりやすい。

結局、何が言いたいかというと
・抽象せず具体的にコメントを書いて欲しい
・コメントに頼るのでなく設計をコンパクトにして仕様を具体化した関数を作成したい
ということで。

PS:抽象化してコメントがある事がけして悪いとは言わない。
設計が明確ならそういう関数も産まれることだろうと思う。