5

C ベースのコード ライブラリ/API の一部であるファイルと関数に名前を付ける正しい方法は何ですか?

4

1 に答える 1

8

できること(すべきではありません) は、完全に不注意であり、体系的な命名規則をまったく使用しないことです。これは「機能」しますが、顧客の生活を不快にします。自分のプログラムで使用できる名前を簡単に知る方法はありません。(私は、内部使用のための文書化されていない関数を定義したライブラリに出くわしましたerror().名前は、外部の文書化された名前空間のどの部分とも一致しませんでした.その時、私自身の標準エラー報告関数の1つも呼び出されましerror()た.つまりerr_error()、そのライブラリでは独自の標準エラー報告関数を使用できませんでした.結果として、必要がなければそのライブラリを使用しませんでした;使用するにはあまりにも面倒でした.)

だから、あなたはそのようであってはなりません。公開する名前には注意が必要です。

パブリック ヘッダーでは、文書化されている 1 つ (またはごく少数) の体系的なプレフィックスを使用する必要があります。通常、PFX などのプレフィックスを選択し、それを使用します。

  • 列挙定数 start PFX_.
  • マクロ開始PFX_
  • 機能開始pfx_
  • グローバル変数 (あなたはそれらのどれも持っていませんよね) start pfx_.
  • 型名と構造体または共用体タグ start pfx_.
  • 独自のソース ファイルの外部に表示されるプライベート変数と関数には、体系的なプレフィックスがあります (おそらくpfx_再び、またはpfxp_最後pがプライベート用である場合、またはpfx[A-Z]プライベート名がキャメル ケース化されているが で始まるためpfx)。

厳密にファイル スコープ (外部リンケージなし) である変数または関数のみがこれらの規則によって制約されませんが、その場合でも、命名規則を使用することをお勧めします (そのため、後で 2 つのファイルで関数を使用する必要がある場合は、.関数が以前にあったコード内の呼び出しを修正する必要はありませんstatic)。

PFX_このようにして、ライブラリによって開始またはpfx_予約されている名前を簡単に文書化できます。ユーザーは引き続き同じ接頭辞を持つ名前を使用できます (停止することはできません) が、ライブラリをアップグレードすると予約済みの名前が追加される可能性があるため、自己責任で使用してください。あなたがそれらを文書化し、文書化が (比較的) 理解しやすいので、彼らはあなたの名前を明確に保つことができます。

C 標準と POSIX 標準の両方が予約名の規則を規定していることに注意してください。ただし、予約済みの POSIX および C 名のルールは、単一のプレフィックスよりもかなり複雑です。彼らも一掃しています。たとえば、_tPOSIX ヘッダーが含まれている場合、POSIX は型名として使用するために末尾がすべての名前を予約しています。

于 2012-04-04T23:11:10.287 に答える