定数のように動作する変数の命名規則

Question

私は定数のように使用している変数を持っています（変わらないでしょう）。実行時に値が追加されるため、定数として宣言することはできません。

データの意味を理解するのに役立つ変数名を大文字にしますか？

またははではありませんが、これは規約に反して物事をより混乱させるためですか？

大きな質問：
シナリオが典型的ではないが、個人的に物事を理解するのに役立つ程度であっても、慣習に従っていますか？

Answer 1

それをカプセル化します。

#include <iostream> 

class ParamFoo 
{ 
    public: 
     static void initializeAtStartup(double x); 
     static double getFoo(); 
    private: 
     static double foo_; 
}; 

double ParamFoo::foo_; 

void ParamFoo::initializeAtStartup(double x) 
{ 
    foo_ = x; 
} 

double ParamFoo::getFoo() 
{ 
    return foo_; 
} 

int main(void) 
{ 
    ParamFoo::initializeAtStartup(0.4); 
    std::cout << ParamFoo::getFoo() << std::endl; 
} 

この値は、アプリケーションの起動時以外には設定しないでください。あなたが保護を追加したい場合は、initializeAtStartupが複数回呼び出された場合に例外をスローするために、いくつかの民間警備boolean変数を追加することができます。

Answer 2

読み取り専用としてマークすることはできますか？その後、慣習はそれほど重要ではありません。

Answer 3

6ヶ月間コードを理解するのに役立つなら、それをやってください。そうでない場合は、しないでください。それは本当に簡単です。

個人的には、私はそれを大文字にします。これは、オブジェクト指向の性質のため実行時に常に定数が割り当てられるJavaの規約です。誤って割り当てた場合、次にコードをスキャンしたときに気付くはずです。

Answer 4

私は変数に名前を付けますが、私は自分の命名を非常に一貫しています。 Robが既に示唆しているように、readonlyについては何か（少なくともC＃で利用可能）。 またはセッターのないプロパティ。

Answer 5

私の人生はここで最も重要だとは思っていません。私がコードを書いたのであれば、それは他の誰よりも必要な時に、それは私が最善を尽くす「他の誰か」、つまり、私が徹底的に（理想的には）コードを理解する必要がある現在のまたは将来のチームメイトです。

さらに、コードベースに何かをコミットするための必須のコードレビュー（優れた習慣と現在の雇用主の確実なルール）では、私はこれまで注目しなければならないスリップ（それは起こります - それが私が他のみんなと同様に自分自身に適用されたように、それらの必須のコードレビューを愛している理由です - ）。

「起動時に一度だけ変更できる変数」は、チームのガイドラインに追加する価値がある特別なケースです。「変数よりも定数に近い」と扱うことは意味がありますが同じルール/ガイドラインがコードベース全体で一貫して使用される場合にのみ役立ちます。ルールがない場合は、ルールの追加についてコンセンサスがあるかどうかを確認します。そうでなければ、私は個人的な味のためにガイドラインを破ることはありません。それは、熱心な熱意を持っている2つの原則である「エコーレスプログラミング」と「コードベースのチームオーナーシップ」の根幹です。

ところで、コーディングガイドラインの面で私は一人のチームで働いていました（それは最適な状況ではありませんが、起こっています）、私は自分自身で全員一致のコンセンサスを得て、起動時に一度 "の変数を命名規則の定数として使用します。しかし、より大きなチームでは、それはより多くの仕事であり、いずれにしても行けます。 シナリオは 大会の代表的な、しかし、それ はあなたを助けるかもしれないことを十分に近接していない場合でも

Answer 6

あなたが規則に従ってください、個人的に、 に物事を理解できますか？

シナリオが非典型的な場合は、他人を混乱させたり遅らせたりする可能性があります（あるいは、しばらくしてから）。私は、変数ではないと思われるものを避けます。

また、このような非典型的なシナリオがあるという事実は、おそらく他のより典型的なパラダイムに従う可能性があることを示している可能性があります。しかし、私には代替案の提案はありません。

Answer 7

私はそれを大文字にします（これは設計上の観点から変数よりも定数です）。アプリケーションに一意性を示すコメントを追加します。

Answer 8

FWIW私の自身の規約は、#defineとenumsのすべての帽子を使用することです。 constの変数については、特にコンベンションを使用していない場合や、「k」（ 'konstant'の場合 - 'c'ではなく、 'count'や 'char'のように既に使用されています） 。

私は 'k'のようなコンベンションが好きで、おそらくそれを頻繁に使用し、恐ろしいプリプロセッサマクロのために叫んでいるオールキャップの識別子を予約してenumとして使用することもあります。

Answer 9

まず、プロジェクトのコーディング基準に従ってください。あなたは自分ではなくコードを読む他の人のためにコーディングする必要があります。

プロジェクトのコーディング規格がない場合は、扱う言語に「ベストプラクティス」を従わなければなりません。

Javaでは、ラクダの大文字と小文字の区別をする疑似定数を宣言することをお勧めします。 Sun Javaのコーディング標準では、それがプロフェッショナルJava開発者の大部分が使用しているものです。

CおよびC++では、プリプロセッサシンボルとして定義された定数にall-capsが使用されています。したがって、これはプリプロセッサのシンボルではないので、コーディング標準が変数に適していると言えるものを使用してください。

擬似定数がに変更されていないという事実は、誰かがコードを変更して誤ってまたは故意に実際に変更されるのを阻止しません。あなたは/本物constaintのような識別子見を行い、コーディング規則を乱用使用する場合は、問題の一部になります：あなたのコードは、最初の識別子が本当であると仮定します/デバッグを読み取ろうと

1. 誰か一定ではない可能性を調査していない。
2. それで彼らが宣言を見ると、怒りと脅威の多くがあるでしょう。 の害悪です。

実際、疑似定数を処理するより良い方法は、カプセル化することです。 Javaでは、それをprivateメンバーとして宣言し、getterとsetterを提供します。設定者は、疑似定数が最初に設定された後に変更されないようにするために何かを行う必要があります。まともなJava JITコンパイラは単純なゲッターをインライン展開するため、実行時のパフォーマンスに影響しないはずです。

Answer 10

表記規則はまさにその慣例です。彼らは、コードを理解するのを助けるためにそこにいます。彼らは通常、あまりにも悪く選ばれておらず、それらが一貫して適用されるならば、そうする。最後の点は、おそらくそれらについての最も重要なものです：彼らは一貫し適用されるべきです。

少なくとも新しいコーラーやコードベースを切り替える人たちが一貫して適用されても、コードをより読みやすくするために、他の規則と矛盾していることがあります。 CおよびC++では、私はALL_CAPSの名前の使用に関する2つの一般的な規則に注意だ：

• は、プリプロセッサのためにそれらを予約します。プリプロセッサ識別子が特別なものであることを好みます。通常のスコープ規則に従わず、それらとの衝突を防ぐことが重要です。

• 定数（マクロおよび列挙子）に使用します。あなたが実際には変数であり、論理的に一定のもののためにそれらを使用する場合

2つの問題が不慣れに加えています：

• 彼らは（配列サイズのような）場所では使用できない場所言語は、定数式に

• 私の経験を期待して、メンテナンスは、彼らが今していることを彼らはさらに少ない一定にする傾向があることを私に教えています。

Answer 11

単一のプライベート静的フィールドを持つラッパークラスを作成します。 initField（..）およびgetField（..）静的メソッドを作成します。静的フィールドがnullでない場合、initFieldはスロー/アサート/その他のエラーをスローします。 （プリミティブのために、あなたは初期化を追跡するために、プリミティブとブール値を使用する必要があります。）

をJavaでは、私は、システムプロパティなどの変数のこれらのタイプを渡すことを好みます。代わりにそれを指定するには、-Dを使用してのあなたはまた、プロパティファイルを使用することができ

public final int MY_INT = Integer.getInteger("a.property.name"); 

（java.util.Propertiesを参照してください）：静的クラスは、次にような何かを行うことができます。次に、あなたは得る：

public class Foo { 

public static final int MY_INT; 

static { 
Properties p = new Properties(); 
try{ 
p.load(new FileInputStream("app.props"): 
} catch(IOException e) { 
//SWALLOW or RETHROW AS ERROR 
} 
MY_INT=Integer.parseInt(p.getProperty("my.int","17")); //17 is default if you swallo IOException 
} 
... 
} 

Answer 12

私の即時の印象は、あなたが「実行時に設定され、その後、決して変わらない」何かが唯一のこれまでのビジネスルールが一定であるとして、一定であるということです。また、ALL CAPSを使用すると "constness"を保証することはほとんどできないので、mutators/accessorを使用する必要があります。

public class BadClass 
{ 
    public static final double PI = 3.1;  
     // PI is very constant. Not according to the business roles modeled by my 
     // application, but by nature. I don't have a problem making this publicly 
     // accessible--except that [Math] already does, with much better precision) 

    public static /*final*/ int FOO = null; 
     // FOO is constant only by convention. I cannot even enforce its "constness". 
     // Making it public means that my enemies (overtime, for example) can change 
     // the value (late night programming), without telling me. 
} 

代わりに、

public class BetterClass 
{ 
    public static final double PI = 3.1; 
    private /*final*/ Integer foo = null; 

    public int getFoo() { 
     return this.foo.intValue(); 
    } 
    public void setFoo(int value) { 
     // The business rules say that foo can be set only once. 
     // If the business rules change, we can remove this condition 
     // without breaking old code. 
     if (null == this.foo) { 
      this.foo = value; 
     } else { 
      throw new IllegalStateException("Foo can be set only once."); 
     } 
    } 
} 

あなたは常に偶数[BetterClass]自体の中に、値を設定するミューテータを使用する場合は、FOOの「const性」が破られることはありませんことを知っています。もちろん、誰かがfooの値を直接設定しようとしている場合（私は午前2時前に仕事をやめる必要があります！）、それでも保証はありません。しかし、そのようなものはコードレビューで指摘されるべきです。

私は、fooを通常のメンバ変数として扱うことをお勧めします。ほぼconstの何かのために特殊な命名規則を使う必要はありません。

ただし、private変数の場合でも、mutators/accessorを使用してください。これらは通常非常に高速で、内部でビジネスルールを実施することができます。これはあなたの慣習でなければなりません。

（埋め込み医療機器のコードを書く場合は、この投稿を見たことがないと思われる）。

Answer 13

間違った情報を与えることは、一般的にベストプラクティスではありません。

暗黙的に何かを主張すると、ただの場合、現在はが変更されていませんが間違った情報が出ています。

Answer 14

1つの質問はどのような変数ですか？

静的変数の場合は、より良い用語の欠如のために "ブート時"と呼ばれるものの後で変更されません、私はALL_CAPSを使用します...グローバル変数についても同じことです...）

通信セマンティクスは、実際には命名規則のポイントであり、ALL_CAPSが明確に述べていることを確認すると、a）私はそれに書きませんb）私はそれを（ローカル変数にたとえば、静的アクセスが非常に遅いため、インスタンス変数でさえ意味があります）...

実際の定数かどうかは関係ありません。隠すべきである（確実に！info ）重要なのは、共有されている情報が信頼できるということです！）...実際に交換することができます...例えば、私はしばしばアプリケーションの構築といくつかのハードコードされた設定、いくつかの静的定数を含んでいます...後で、私はこれをハードコードするのではなく、いくつかの設定ファイルから来て、私はそれをロードし、ブートプロセス中に、私はすべての擬似定数を初期化する...起動後、これらの値は...これは私にとって完全に有効なようです...

私は今まで実行した場合、私は100％確信していません私は非常に確かなことができるケースに、いくつかのフィールドは決して変化しないだろう...通常、これはクラスをフレキシブルにする。

他のthaあなたは通常、読み込み専用のプロパティを宣言してコンパイル時にエラーを発生させることができます。これは良いことです...

Answer 15

私はこれが正しい言語であるかどうかは分かりませんが、これはあなたのために働くだろう：（あなたが本当にあなたのメモリを必要としない限り）

#include <iostream> 

int main() 
{ 
    int i = 0; 
    std::cin >> i; 

    const int CONST = i; 
    std::cout << CONST; //displays i 

    system("PAUSE"); 
    return 0; 
} 

は、私はこれを行うための道徳的なものであるかどうかわからないんだけど、これはあなたの問題を解決しません。

Answer 16

何か他のものと同様に、スコープとコンテキストは何かが一定であることを知るために必要です。だから誰も満足させる方法はない。

あなたの言語で使用されているスタイルに従います - 時間の80％、それは十分に明確です。その代わりに、理想的な技術的正確性のために生産性を犠牲にしている非常に過度に名づけられたシステムです（これを達成することができれば、）