問題タブ [naming-conventions]

「通常の」変数と簡単に区別できるように、メンバー変数に接頭辞を付けることがコードを理解する上で不可欠であることは間違いありません。

しかし、どのようなプレフィックスを使用しますか?

私はm_をプレフィックスとして使用するプロジェクトに取り組んできましたが、他のプロジェクトではアンダースコアのみを使用しました (アンダースコアのみでは十分に実証できないため、個人的には好きではありません)。

別のプロジェクトでは、変数の型も含む長いプレフィックス形式を使用しました。たとえば、mul_はunsigned long 型のメンバー変数のプレフィックスです。

使用しているプレフィックスの種類を教えてください (その理由を教えてください)。

編集:ほとんどの人は、メンバー変数に特別な接頭辞を付けずにコーディングしているようです! これは言語に依存しますか？私の経験から、C++ コードではメンバー変数のプレフィックスとしてアンダースコアまたはm_を使用する傾向があります。他の言語はどうですか？

コード ビハインド ページで参照できるように、フォームやレポートの UI コントロール (テキスト ボックス、ドロップダウンなど) に名前を付けるためのベスト プラクティスは何ですか?

私は自分のオフィスで多くのレポートとフォームを作成しています。さまざまな複数のデータ ソース (Access、SQL、Oracle) から生成される約 80 以上の「ライブ」レポートを提供する Web アプリケーションがいくつかあります。これらのレポートは「ライブ」と見なされます。フォームからユーザー セット パラメータを受け取り、データベースにクエリを実行して、利用可能な現在の情報に基づいてレポートを生成するためです。

したがって、プロセスは、ユーザーが設定した値を取得することから始まり、それらをデータベース クエリに渡し、データセットを受け取り、最後にデータセットをレポートに割り当てます。場合によっては、レポートを生成する前に、レポートに表示される追加のフィールドをデータセットから計算する必要があります。これには、レポートの出力コントロールを参照して計算値を割り当てる必要があります。

コード内で変数やメンバー フィールドに接頭辞を使用することはあまり気にしませんが、UI コントロールを識別するために接頭辞を使用しています。たとえば、txtFirstName でレポート コントロールを参照し、データセットの FirstName フィールドのデータをレポートの表示コントロールに割り当てます。フォームやレポートの UI コントロールに名前を付けたり参照したりするためのより良い方法はありますか?

私はハンガリー語が何を指しているのか知っています-変数、パラメーター、またはタイプに関する情報をその名前の接頭辞として提供します。場合によってはそれが良い考えであるように思われるとしても、誰もがそれに激しく反対しているようです。有用な情報が伝えられていると感じたら、それを入手可能な場所に置いてはいけないのはなぜですか。

参照：人々は現実の世界でハンガリー語の命名規則を使用していますか？

Web サービスと通信するデスクトップ アプリケーションを作成しています。実行に時間がかかるため、データを取得するすべての Web サービス関数の名前をXXXXに指定してください。または、たとえば単一のオブジェクトを取得する場合など、Get XXXX を使用しますか。

私は、LLBLGen がデータベース構造に基づいてオブジェクトを生成するときに提供するレイアウトに慣れています。これにより、データベース内の特定の「ユーザー」テーブルに対して次のクラス ファイルが生成される可能性があります。

これにより、データ アクセスの基本機能が提供されます。しかし、その上にビジネスロジックを実装したい場合、どのようにレイアウトしますか? たとえば、次のようなテーブル構造があるとします。

ユーザーをロックアウトしたい場合はどうしますか? プレゼンテーション層からどのコードを呼び出しますか? UserEntity クラスをインスタンス化して、次のことを行いますか?

または、UserHelper (/BusinessLogic/UserHelper.cs) などの新しいクラスを作成します。これには、LockOutUser 関数が含まれている可能性があります。これにより、コードは次のように変更されます。

それとも、基本の UserEntity クラスを拡張し、新しい機能を追加する UserEntityExt を作成しますか? したがって、プレゼンテーション層のコードは次のようになります。

それとも…まったく別のことをしますか？

また、ディレクトリ/名前空間の構造とファイル/クラスの命名規則はどうなりますか?

/about_usと/about-us のどちらにするべきですか?

使いやすさの観点から、私は個人的に/about-usがエンドユーザーにとってはるかに優れていると考えていますが、Google や他のほとんどの Web サイト (および JavaScript フレームワーク) はアンダースコアの命名パターンを使用しています。スタイルだけの問題ですか？ダッシュとの互換性の問題はありますか?

jar ファイルの命名に関する業界標準の規則はありますか?

コーディング中に使用する命名規則は何ですか?

変数の命名規則に関する限り、イテレータには名前を付ける必要がありますか、iそれとももっとセマンティックな名前を付ける必要がありますcountか？使わないのならi、どうして？それが許容できると感じたi場合、それを使用すべきではない反復のケースはありますか？

「InstructionBuilderFactoryMapFactory」というクラスを作成していることに気づきました。これは、1つのクラスの4つの「パターン接尾辞」です。それはすぐに私にこれを思い出させました：

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

これはデザインの匂いですか？この数に制限を課す必要がありますか？

一部のプログラマーが他のことについて同様のルールを持っていることを私は知っています（たとえば、Cでのポインター間接参照のNレベル以下）。

すべてのクラスが私には必要なようです。私は文字列からファクトリへの（固定された）マップを持っています-私はいつも何かをしています。リストは長くなりつつあり、ビルダー（マップから取得したファクトリによって作成されたもの...）を使用するクラスのコンストラクターからリストを移動したいと思います。いつものように、シングルトンは避けています。