他の誰かが、クラスとメソッドの命名をプログラミングで最も難しい部分の1つだと思いますか？[閉まっている]

だから私はこのクラスに取り組んでいます。このクラスはベンダーにWebサービスを通じてヘルプドキュメントを要求することになっています。私はそれを名前にしようとDocumentRetriever、VendorDocRequester、DocGetter、しかし、彼らはちょうど鳴りません。結局、dictionary.comを30分ブラウジングして、適切な単語を思いついた。

悪い名前を使ってプログラミングを始めるのは、午前中に非常に悪い髪の日をするようなもので、残りの日はそこから下り坂になります。私を感じる？

あなたが今行っていることは問題ありません。現在の構文に固執することを強くお勧めします。

コンテキスト+動詞+方法

私はこのメソッドを使用して、関数/メソッド、SQLストアドプロシージャなどに名前を付けます。この構文を維持することで、Intellisense /コードペインがずっときれいになります。したがって、EmployeeGetByID（）、EmployeeAdd（）、EmployeeDeleteByID（）が必要です。GetEmployee（）、AddEmployee（）などのより文法的に正しい構文を使用すると、同じクラスに複数のGetがある場合、無関係なものが一緒にグループ化されるため、これが非常に乱雑になることがわかります。

これを日付の付いたファイルの名前付けに似ています。1-7-2009.logではなく2009-01-07.logと言いたいのですが、それらがたくさんあると、順序はまったく役に立たなくなります。

私が学んだ1つの教訓は、クラスの名前が見つからない場合、ほとんど常にそのクラスに問題があるということです。

• あなたはそれを必要としません
• やりすぎ

適切な命名規則により、特定の変数、クラス、メソッド、または関数に使用できる名前の数を最小限に抑える必要があります。可能な名前が1つしかない場合は、名前を覚えるのに問題はありません。

関数とシングルトンクラスの場合、関数を精査して、その基本的な機能が、ある種類のものを別の種類のものに変換することであるかどうかを確認します。私はその用語を非常に大まかに使用していますが、あなたが書いた膨大な数の関数が本質的にある形式で何かを取り、別の形式で何かを生成することに気付くでしょう。

あなたの場合、あなたのクラスがURLをドキュメントに変換するように聞こえます。そのように考えるのは少し奇妙ですが、完全に正しいです。このパターンを探し始めると、どこにでもそれが表示されます。

このパターンを見つけたときは、常に関数にx Fromyという名前を付けます。

あなたの関数はURLをドキュメントに変換するので、私はそれに名前を付けます

DocumentFromUrl

このパターンは非常に一般的です。例えば：

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

またUrlToDocument、その順序で問題がなければ、使用することもできます。x Fromyと言うかy Toxと言うかは、おそらく好みの問題ですFromが、関数名の先頭から、どの型が返されるかが既にわかっているため、順序を優先します。

慣習を1つ選び、それに固執する。x Fromy関数でクラス名と同じ名前を使用することに注意すると、使用した名前を覚えやすくなります。もちろん、このパターンはすべてに対して機能するわけではありませんが、「機能的」と見なすことができるコードを記述しているところで機能します。

クラスまたはメソッドに適切な名前がない場合がありますが、それは私たち全員に起こります。ただし、多くの場合、名前を付けることができないことが、設計に問題があることのヒントになることがあります。メソッドの責任が多すぎますか？あなたのクラスは首尾一貫したアイデアをカプセル化していますか？

スレッド1：

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

スレッド2：

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

ここにはThread.sleep（...）はありません。

プログラミングをしているときに名前を付けることができるものの名​​前についても心配しています。私はそれが非常にうまくいくと思います。時々私が行き詰まっているとき、私はそれをしばらくそのままにし、コーヒーブレーク中に誰かに良い提案があるかどうか少し尋ねます。

あなたのクラスのために私はお勧めしVendorHelpDocRequesterます。

Steve Mcconnellの著書であるCode Completeには、変数/クラス/関数/の命名に関する素晴らしい章があります...

これは副作用だと思います。

難しいのは、実際のネーミングではありません。難しいのは、名前を付けるプロセスによって、何をしているのかまったくわからないという恐ろしい事実に直面することです。

37SignalsのSignal vs. Noiseブログで昨日この引用を聞いたばかりで、確かにそれに同意します。

「コンピューターサイエンスには、キャッシュの無効化と名前付けという2つの難しいことしかありません。」—フィル・カールトン

難しいのはいいですね。それはあなたに問題とクラスが実際に何をすることになっているのかについて考えることを強いています。優れた名前は、優れたデザインにつながります。

同意した。型の名前と変数をできるだけ長く説明しすぎないようにしたいのですが、適切な単語を見つけることができない特定の概念がある場合があります。

その場合、同僚に入力を依頼することは常に助けになります-最終的に助けにならない場合でも、通常、それを少なくとも大声で説明し、車輪を回すのに役立ちます。

先月、命名規則について書いていました：http : //caseysoftware.com/blog/useful-naming-conventions

その要点：

verbAdjectiveNounStructure-オプションのパーツとしての構造と形容詞

動詞については、保存、削除、通知、更新、または生成というアクション動詞を使用します。たまには「プロセス」を使用しますが、キューまたは作業バックログを具体的に参照するためだけに使用します。

以下のために名詞、私はと相互作用しているクラスやオブジェクトを使用します。web2projectでは、これは多くの場合、タスクまたはプロジェクトです。JavaScriptがページとやり取りしている場合は、本文またはテーブルである可能性があります。重要なのは、コードは、相互作用するオブジェクトを明確に記述しているということです。

構造は、それは状況に固有だから、オプションです。リスト画面は、リストまたは配列を要求する場合があります。web2projectのプロジェクトリストで使用されるコア関数の1つは、単にgetProjectListです。基礎となるデータを変更するのではなく、データの表現を変更するだけです。

形容詞は完全に何か他のものです。それらは名詞の修飾子として使用されます。getOpenProjectsと同じくらい簡単なものは、getProjectsとスイッチパラメーターを使用して簡単に実装できますが、これにより、オブジェクトの基礎となるデータや構造をかなり理解する必要があるメソッドが生成される傾向があります。奨励します。より明示的で特定の関数を使用することで、実装を完全にラップして、それを使用するコードから隠すことができます。それがオブジェクト指向のポイントの1つではないですか？

クラスに名前を付けるだけではなく、適切なパッケージ構造を作成することは困難ですが、やりがいのある課題です。モジュールの懸念を分離し、それらがアプリケーションのビジョンとどのように関連するかを検討する必要があります。

今すぐアプリのレイアウトを検討してください：

• アプリ
  • VendorDocRequester（Webサービスから読み取り、データを提供）
  • VendorDocViewer（リクエスタを使用してベンダードキュメントを提供）

いくつかのクラスではいろいろなことが起こっていると思います。これをよりMVC化されたアプローチにリファクタリングし、小さなクラスが個々の職務を処理できるようにする場合、次のような結果になる可能性があります。

• アプリ
  • VendorDocs
    • 型番
      • ドキュメント（データを保持するプレーンオブジェクト）
      • WebServiceConsumer（Webサービスの重要な要素に対処する）
    • コントローラ
      • DatabaseAdapter（ORMまたはその他のメソッドを使用して永続性を処理する）
      • WebServiceAdapter（コンシューマーを利用してドキュメントを取得し、データベースに貼り付けます）
    • 見る
      • HelpViewer（DBAdapterを使用してドキュメントを吐き出します）

次に、クラス名は名前空間に依存して完全なコンテキストを提供します。クラス自体は、明示的にそう言う必要なしに、アプリケーションに本質的に関連することができます。結果として、クラス名はより簡単に定義できます！

もう1つの非常に重要な提案：自分でお願いして、Head First Design Patternsのコピーを入手してください。それはあなたのアプリケーションを整理し、より良いコードを書くのに役立つ素晴らしい、読みやすい本です。設計パターンを理解することは、遭遇する問題の多くが既に解決されており、ソリューションをコードに組み込むことができることを理解するのに役立ちます。

Leo Brodieは彼の著書「Thinking Forth」で、プログラマーにとって最も困難な作業は適切に名前を付けることであり、最も重要なプログラミングツールはシソーラスであると述べました。

http://thesaurus.reference.com/にあるシソーラスを使用してみてください。

それを超えて、これまでハンガリー記法を使用しないでください。略語を避け、一貫してください。

ご多幸を祈る。

要するに：
私は良い名前が重要であることに同意し、私はあなたがすべてのコストで実装する前にそれらを見つけるために持っていないと思います。

もちろん、最初から良い名前を付ける方が良いでしょう。しかし、2分の1が思いつかない場合は、後で名前を変更する方が時間もかかりません。生産性の観点からは正しい選択です。

長い：
一般に、実装する前に名前についてあまり長く考えることは価値がありません。クラスを実装する場合は、クラスに「Foo」または「Dsnfdkgx」と名前を付けます。実装中には、名前を付ける必要があるものを確認します。

特にJava + Eclipseでは、すべてのクラスのすべての参照を注意深く処理し、名前の衝突などを警告するので、名前の変更はまったく問題ありません。また、クラスがまだバージョン管理リポジトリにない限り、私はしませんt 5回の名前変更に問題があると思います。

基本的に、それはあなたがリファクタリングについてどう考えるかという問題です。個人的には、私はそれが好きですが、実行中のシステムに触れないことを信じているため、私のチームメイトが時々面倒です。そして、リファクタリングできるすべてのものから、名前を変更することは、あなたができる最も無害なことの1つです。

HelpDocumentServiceClientを一口にしたり、HelpDocumentClientにしたりしないでください。ベンダーであっても、ヘルプドキュメントを処理するWebサービスのクライアントであることが重要です。

そしてネーミングは難しいです。

そのクラスに意味のある名前は1つだけです。

HelpRequest

実装の詳細が意味を混乱させないようにしてください。

優れたリファクタリングツールに投資してください！

私は基本に固執します：VerbNoun（arguments）。例：GetDoc（docID）。

ファンシーを取得する必要はありません。あなたであろうと誰かであろうと、これから1年は理解しやすいでしょう。

私にとっては、メソッドまたはクラスの名前が、説明と正しいライブラリにある限り、どれだけ長くてもかまいません。APIの各部分がどこにあるかを覚えておく必要はありません。

Intelisenseはすべての主要言語に対応しています。したがって、サードパーティのAPIを使用する場合は、「実際の」ドキュメントを使用するのではなく、そのIntellisenseをドキュメントに使用したいと思います。

そのことを念頭に置いて、次のようなメソッド名を作成しても問題ありません。

StevesPostOnMethodNamesBeingLongOrShort

長いですが、何でしょう。最近24インチスクリーンを使用していないのは誰ですか。

ネーミングは芸術であることに同意する必要があります。クラスが特定の "desigh pattern"（工場など）に従っている場合、少し簡単になります。

これは、コーディング標準を持つ理由の1つです。標準を持つことは、必要なときに名前を思い付くのに役立つ傾向があります。それはあなたの心を解放して他のより興味深いものに使うのを助けます！（-：

Steve McConnellのコードコンプリート（Amazonリンク）の関連する章を読むことをお勧めします。

HTH

乾杯、

ロブ

いいえ、デバッグは私にとって最も難しいことです！:-)

DocumentFetcher？コンテキストがないと言うのは難しいです。

数学者のように振る舞い、ドメインのレキシコンを借りたり、発明したりするのに役立ちます。コンセプトを示唆する短い平易な単語を、毎回綴ることなく解決してください。頭字語に変わる長いラテン語のフレーズをよく見るので、とにかく頭字語の辞書が必要になります。

問題の説明に使用する言語は、変数、メソッド、オブジェクト、クラスなどに使用する言語です。おおまかに言って、名詞はオブジェクトに一致し、動詞はメソッドに一致します。問題を説明する言葉がない場合、問題の完全な理解（仕様）もありません。

名前のセットから選択するだけの場合は、システムの構築に使用している規則によって決定されます。以前の規則でカバーされていない新しい場所に来た場合、この新しいケースをカバーするためにそれらを（適切に、一貫して）拡張しようとする努力に常に費やす価値があります。

疑問がある場合は、寝て、最初の最も明白な名前、翌朝を選んでください:-)

ある日目を覚まして、自分が間違っていたことに気づいたら、すぐに変えてください。

ポール。

ところで：Document.fetch（）はかなり明白です。

私はローカル変数で最も問題を抱えていることがわかりました。たとえば、DocGetterタイプのオブジェクトを作成します。だから私はそれがDocGetterであることを知っています。なぜ別の名前を付ける必要があるのですか？私は通常、dg（DocGetterの場合）やtempなど、わかりにくい名前を付けます。

デザインパターン（GoFだけではない）は、一般的な語彙を提供する良い方法であり、状況に適した場合は常にその名前を使用することを忘れないでください。これは、命名法に精通している初心者でも、アーキテクチャをすばやく理解するのに役立ちます。あなたが取り組んでいるこのクラスは、プロキシ、またはファサードのように動作するはずですか？

ベンダーのドキュメントを対象にすべきではありませんか？つまり、それは具体的なものであり、プログラムの一部の擬人化ではありません。したがって、VendorDocumentation情報をフェッチするコンストラクターを持つクラスがある場合があります。クラス名に動詞が含まれていると、何かがおかしくなっていることがよくあります。

私は間違いなくあなたを感じています。そして、私はあなたの痛みを感じます。私が思うすべての名前は、私にはごみのようです。それはすべて非常に一般的であるように思われ、私は最終的に私の名前に少しのセンスと創造性を注入する方法を学び、彼らが彼らが説明するものを本当に反映するようにします。

私が持っている提案の1つは、シソーラスを参照することです。Wordには良いものがあります。MacOS Xもそうです。それは本当に頭を雲から降ろすのに役立ち、良い出発点とインスピレーションを与えてくれます。

名前が素人プログラマーに説明される場合は、おそらくそれを変更する必要はありません。