タグ付けされた質問 「naming」

以前は、命令/レジスタ名を短くする非常に良い理由がありました。これらの理由はもはや当てはまりませんが、低レベルのプログラミングでは依然として短い暗号名が非常に一般的です。 どうしてこれなの？古い習慣が破れにくいからといって、それとももっと良い理由があるのでしょうか？ 例えば： Atmel ATMEGA32U2（2010？）：（のTIFR1代わりにTimerCounter1InterruptFlag）、ICR1H（の代わりにInputCapture1High）、DDRB（の代わりにDataDirectionPortB）など。 .NET CLR命令セット（2002）：（のbge.s代わりにbranch-if-greater-or-equal.short）など。 長くて、暗号化されていない名前を使用する方が簡単ではありませんか？ 回答および投票する際は、以下を考慮してください。ここで提案されている説明の多くは高レベルのプログラミングにも同様に当てはまりますが、コンセンサスは概して、1つまたは2つの単語からなる非暗号化名を使用することです（一般に理解されている頭字語は除外されます）。 また、あなたの主な議論が紙の図の物理的な空間に関するものである場合、これはアセンブリ言語またはCILには絶対に適用されないことを考慮してください。さらに、簡潔な名前が収まるが読みやすいものが図を悪化させる図を見せていただければ幸いです。ファブレス半導体会社での個人的な経験から、読みやすい名前はうまく適合し、より読みやすい図になります。 高レベル言語ではなく、低レベルプログラミングで簡潔な名前を望ましいものにする高レベル言語とは異なる、中核となるものは何ですか？

64 naming  coding-standards  low-level 

クラス名に単数形と複数形を選択することは、私にとって常に困難です。 CustomerRepository vs. CustomersRepository CustomerService vs. CustomersService CustomerController vs. CustomersController また、複合名の場合はさらに難しくなります。 OrderCustomerRepository対OrderCustomersRepository対OrdersCustomersRepository どのアプローチを好むのですか？

58 naming  source-code 

ブール値を返すメソッドのより良い名前はどれですか？ IsSupportContentType または CanSupportContentType

51 naming  naming-standards 

コンセンサスは、開発対象のプラットフォームの規則に従う必要があるということです。見る： アンダースコアまたはラクダケース？ 命名規則：camelCase対underscore_case？ ただし、PHPはメソッドや関数（mysqli::set_local_infile_default、 など）についても、内部的には規則に厳密に従っていないようです（そこに驚くことはありませんPDOStatement::debugDumpParams）。ただし、関数名ではアンダースコアが支配的であるようです。 しかし、私が見つけることができなかったのはこれでした：PHPの変数の支配的な命名規則は何ですか？

51 php  naming  readability  camelcase 

isブール変数のプレフィックスとして常に使用する必要がありますか？過去の何かを示すブール値はどうですか？私が書く必要がありますisInitializedかwasInitialized？私は性質のために書くべきですIsManyMembersかHasManyMembers？ ベストプラクティスはありますか？または、私はただ英語の規則に従って書くべきですか？

50 coding-style  naming  boolean 

以下の一般的なガイダンスで、コーナーケースの問題に遭遇しました。 変数の名詞 関数の動詞 具体的には、単語があいまいな場合があります-動詞または名詞のいずれかです。また、アプリケーションについて説明している場合には、同じ文で両方の方法で使用されます。 私の意図は、数か月後にコードのセクションに戻ったときに、自分自身だけでなく将来の開発者にもプログラムが読めるようにすることです。 例の1つはbatteryです。Aにbatteryはバッテリーchargeがありcharge()ます。 両方を持つことはBattery.Charge、Battery.Charge(value)将来の開発者にとって混乱を招くと思います。 私の現在の解決策は、これらのケース（変数と関数）のいずれかまたは両方に対して異なる単語を選択することです。そのアプローチに関する私の問題は、Batteryオブジェクトの変数と関数がchargeを含む設計の議論と一致しないことBatteryです。 私の質問は、命名規則のこの競合を処理する別の/より良い方法があるかどうかです。 件名に関するいくつかの追加の読書。私の質問の特定に実際に取り組んだものはありません。 意味のある簡潔なメソッド命名ガイドライン 変数の命名規則 https://softwareengineering.stackexchange.com/questions/14169/what-naming-guidelines-do-you-followから選択した回答

48 naming  variables 

getSomethingvsで始まる特定のメソッドに名前を付ける必要があるかどうかを判断するのは常に困難findSomethingです。 問題は、設計が不十分なAPIのヘルパーを作成することにあります。これは通常、オブジェクトからデータを取得するときに発生し、オブジェクトをパラメーターとして必要とします。以下に簡単な例を示します。 public String getRevision(Item item) { service.load(item, "revision"); // there is usually more work to do before getting the data.. try { return item.get_revision(); } catch(NotLoadedException exception) { log.error("Property named 'property_name' was not loaded", exception); } return null; } このメソッドの名前をgetRevision()orにするfindRevision()かどうか、どのように決めるのですか

48 naming  methods 

良くも悪くも予約語になっている一般的な単語の意図的なスペルミスを含むコードをよく見ます： klassまたはclazzのためのクラス：Class clazz = ThisClass.class kount以下のためのカウント SQLで：count(*) AS kount 個人的には、これにより可読性が低下することがわかります。私自身の練習では、私はより良い名前が使用されていることができなかった、あまりにも多くのケースを発見していません- itemClassかrecordTotal。 クラスのJavaDocsの例は、パラメーターにこれを示しています。 public <U> Class<? extends U> asSubclass(Class<U> clazz) これは合理的なユースケースを示していますか？

45 coding-style  variables  readability  naming 

多くの場合、言語の構文で使用されない変数に名前を付ける必要がある場合は、名前を付け_ます。 私の考えでは、これにより混乱が減り、コード内の意味のある変数に集中できます。「目立たない、気にしない」効果を生み出すように、目立たないことがわかりました。 私がこれを行う場所の一般的な例は、SQLでサブクエリに名前を付けることです。 SELECT * FROM ( SELECT * FROM TableA JOIN TableB ON TableA.ColumnB = TableB.ColumnB WHERE [ColumnA] > 10 ) _ --This name is required, but never used here ORDER BY ColumnC 別の例は、使用されないループ変数です。 array = [[] for _ in range(n)] # Defines a list of n empty lists …

44 language-agnostic  naming  readability  variables 

メソッドが返す変数を変数名で呼び出すのは良い習慣resultですか？ 例えば： public Zorglub calculate() { Zorglub result = [...] [...] return result; } または、タイプ別に名前を付ける必要がありますか？ public Zorglub calculate() { Zorglub zorglub = [...] [...] return zorglub; } 私は両方を野生で見ましたが、どちらかを選択する必要がある場合、前者または後者（またはより良い名前）を好む理由は何ですか？ 私は主にJavaについて考えています。

44 programming-practices  naming  variables 

ブール型メソッドは、否定的な形式でのみ使用される場合でも、常に肯定的な形式を取る必要がありますか？ エンティティを作成する前にエンティティが存在するかどうかを確認したかったとしましょう。私の主張は、メソッドが肯定的なフォームで使用されているかどうかに関係なく、下の最初のフォームは2番目のフォームより優れているということです。 要約すると、私はif(!affirmative)よりも読みやすいと思いますif(negative)。意見が合わない同僚がいますか？ 最初のフォーム： int entity_id = 42; if(!entity_exists(entity_id)) create_entity(entity_id); 2番目のフォーム： int entity_id = 42; if(entity_not_exist(entity_id)) create_entity(entity_id);

43 naming  functions 

私は次のことをどうしたらいいかわかりません： 独自のツール内の外部ツールからデータを取得します。このデータはオランダ語で書かれています。Javaコードを英語で書いています。次に、このオランダ語を英語に翻訳するか、オランダ語のままにする必要がありますか？たとえば、2つの部門があります：Bouw（英語の建設）とOnderhoud（英語の保守）。 作成するのは論理的ですか？ public enum Department { BOUW, ONDERHOUD } または： public enum Department { CONSTRUCTION, MAINTENANCE } あるいは： public enum Afdeling { BOUW, ONDERHOUD } （アフェデリングはオランダ語の学科です）

39 naming  translate 

ここからsmurf命名という用語を取りました（21番）。トラブルに慣れていない人を救うために、Smurfの命名は、関連するクラス、変数などの束に共通の接頭辞を付ける行為であるため、「a SmurfAccountViewpass SmurfAccountDTOto to SmurfAccountController」などになります。 私がこれに対して一般的に聞いた解決策は、smurf名前空間を作成し、smurfプレフィックスを削除することです。これは一般的に私に役立ちましたが、私は2つの問題に直面しています。 私はConfigurationクラスを持つライブラリで作業しています。呼び出すこともできましたがWartmongerConfiguration、Wartmonger名前空間にあるため、単に呼び出されConfigurationます。同様Configurationに呼び出すことができるクラスもありますSmurfConfigurationが、それはSmurf名前空間にあるため、冗長になります。私のコードにSmurf.Configurationは横に表示される場所があり、Wartmonger.Configuration完全修飾名を入力するのは面倒で、コードが読みにくくなります。SmurfConfigurationand（ライブラリではなく私のコードである場合）を扱う方が良いでしょうWartmongerConfiguration。 私はServiceSmurf名前空間で呼び出されたクラスを呼び出しましたSmurfService。Smurfジョブを実行する複雑なSmurfライブラリの上にServiceあるファサードです。Smurf接頭辞がなければ非常に一般的なSmurfServiceため、より良い名前のようServiceです。それSmurfServiceはすでに一般的で役に立たない名前であり、スマーフを取り除くことはこれをより明白にしただけだと認めることができます。しかし、、などと命名することもできますがRunner、Launcherそれでも「気分が良くなる」SmurfLauncherのLauncherは、a が何をするのかわからないからですが、a SmurfLauncherが何をするのかは知っているからです。あなたは、a Smurf.Launcherがすることはa と同じように明白であるべきだと主張することができますSmurf.SmurfLauncher、しかし、 `Smurf.Launcherは、smurfsを起動するクラスではなく、セットアップに関連する何らかのクラスであることがわかりました。 これらのいずれかに対処するためのオープンな方法と閉じた方法があれば、それは素晴らしいことです。そうでない場合、彼らの迷惑を軽減するための一般的な慣行は何ですか？

39 naming  coding-standards 

メソッドを引数名（型ではなく）で区別するだけで十分ですか、それとも明示的に名前を付ける方がよいでしょうか？ たとえば、T Find<T>(int id)VS T FindById<T>(int id)。 ById引数名だけを保持するのではなく、より明示的に名前を付ける（つまり、追加する）正当な理由はありますか？ 私が考えることができる理由の1つは、メソッドのシグネチャが同じであるが、意味が異なる場合です。 FindByFirstName(string name) そして FindByLastName(string name)

36 c#  naming  coding-standards  conventions  method-overloading 

いくつかの名前があります。それらの名前に手を伸ばせば、すでに何かを台無しにしていることがわかります。 例えば： XxxManager クラスはクラスが何をするのかを記述する必要があるため、これは良くありません。クラスが行うことに対して思いつく最も具体的な単語が「管理」である場合、クラスは大きすぎます。 他にどのようなアンチパターンが存在しますか？ 明確にするために、私は「どのような名前が悪いのか」とは問いません。その質問は完全に主観的なものであり、それに答える方法はありません。「システムの全体的な設計上の問題を示す名前は何ですか」と私は尋ねています。つまり、コンポーネントXyzを呼び出したい場合は、おそらくコンポーネントが不十分であることを示しています。また、すべてのルールには例外があることに注意してください-私は本当にデザインを停止して再考する必要がある場合の警告フラグを探しています。

35 naming  anti-patterns