288

そこで私は、Web サービスを介してベンダーにヘルプ ドキュメントを要求することになっているこのクラスに取り組んでいます。DocumentRetrieverVendorDocRequester、と名付けようとしましたDocGetterが、正しく聞こえません。私は、適切な単語を見つけようとして、dictionary.comを 30 分間ブラウジングすることになりました。

悪い名前でプログラミングを開始することは、朝の髪の毛が非常に悪い日を過ごしているようなもので、その日の残りはそこから下り坂になります. 私を感じる?

4

42 に答える 42

61

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

  • あなたはそれを必要としません
  • それはやりすぎ
于 2009-01-08T11:19:31.957 に答える
54

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

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

あなたの場合、クラスが Url を Document に変換するように聞こえます。そのように考えるのは少し奇妙ですが、完全に正しいです。このパターンを探し始めると、どこにでもあります。

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

あなたの関数は Url を Document に変換するので、名前を付けます

DocumentFromUrl

このパターンは意外と多いです。例えば:

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

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

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

于 2009-01-08T03:21:55.507 に答える
32

クラスやメソッドに適切な名前がない場合がありますが、それは誰にでも起こります。ただし、多くの場合、名前を思い付くことができないことは、設計に問題があることを示唆している可能性があります。メソッドの責任が多すぎませんか? あなたのクラスは一貫したアイデアをカプセル化していますか?

于 2009-01-07T20:41:52.647 に答える
29

スレッド 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(...) はありません。

于 2009-01-07T21:07:38.150 に答える
24

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

あなたのクラスにはVendorHelpDocRequester.

于 2009-01-07T20:39:59.673 に答える
20

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

于 2009-01-07T22:06:28.297 に答える
17

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

難しいのは実際のネーミングではありません。難しいのは、ネーミングの過程で、自分が何をしているのかわからないという恐ろしい事実に直面することです。

于 2009-05-30T22:52:36.080 に答える
12

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

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

于 2009-01-07T23:12:57.290 に答える
8

難しいことは良いことです。問題について、そしてクラスが実際に何をすべきかについて考える必要があります。良い名前は良いデザインにつながります。

于 2009-01-07T20:40:40.013 に答える
6

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

その要点:

verbAdjectiveNounStructure - オプションの部分として構造と形容詞を使用

動詞については、アクション動詞 (保存、削除、通知、更新、または生成) に固執します。ときどき「プロセス」を使用しますが、キューや作業のバックログを具体的に指す場合にのみ使用します。

名詞については、相互作用するクラスまたはオブジェクトを使用します。web2project では、これは多くの場合、タスクまたはプロジェクトです。ページと対話する Javascript の場合、それは body または table である可能性があります。ポイントは、コードが対話しているオブジェクトを明確に記述しているということです。

構造は状況に固有であるため、オプションです。リスト画面では、List または Array が要求される場合があります。web2project のプロジェクト リストで使用されるコア関数の 1 つは、単純に getProjectList です。基になるデータは変更されず、データの表現のみが変更されます。

形容詞はまったく別のものです。それらは名詞の修飾語として使用されます。getOpenProjects のような単純なものは、getProjects と switch パラメーターを使用して簡単に実装できますが、これにより、基になるデータやオブジェクトの構造についてかなりの理解を必要とするメソッドが生成される傾向があります...必ずしも必要なものではありません奨励します。より明示的で具体的な関数を使用することで、実装を完全にラップして、それを使用するコードから非表示にすることができます。それがOOのポイントの一つではないでしょうか。

于 2009-01-08T04:00:47.147 に答える
6

同意した。型名と変数は、極端に長くなりすぎずに、できるだけわかりやすいものにするのが好きですが、適切な言葉が見つからない特定の概念が時々あります。

その場合、同僚に意見を求めることが常に役に立ちます。最終的には助けにならなくても、少なくとも声に出して説明し、車輪を回すのに役立ちます。

于 2009-01-07T20:41:45.317 に答える
5

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

ここで、アプリのレイアウトを検討してください。

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

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

  • アプリ
    • ベンダードキュメント
      • モデル
        • ドキュメント (データを保持するプレーンなオブジェクト)
        • WebServiceConsumer (Web サービスの核心を扱う)
      • コントローラ
        • DatabaseAdapter (ORM またはその他の方法を使用して永続化を処理します)
        • WebServiceAdapter (Consumer を利用して Document を取得し、データベースに貼り付けます)
      • 意見
        • HelpViewer (DBAdapter を使用してドキュメントを吐き出します)

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

もう 1 つの非常に重要な提案があります。ぜひ、Head First Design Patterns のコピーを手に取ってください。アプリケーションを整理し、より優れたコードを作成するのに役立つ、素晴らしく読みやすい本です。デザイン パターンを理解することで、遭遇した問題の多くが既に解決されていることを理解し、解決策をコードに組み込むことができます。

于 2009-01-07T21:28:56.437 に答える
4

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

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

それ以上は、ハンガリー語表記法を絶対に使用せず、省略形を避け、一貫性を保つようにしてください。

幸運をお祈りしています。

于 2009-01-08T02:59:49.610 に答える
4

要するに
、良い名前が重要であることには同意しますが、実装する前にそれらを見つける必要はないと思います。

もちろん、最初から良い名前を付けたほうがいいです。ただし、2 分で名前を変更できない場合は、後で名前を変更する方が時間がかからず、生産性の観点からは正しい選択です。

長い:
通常、実装する前に名前についてあまり長く考えることは価値がありません。クラスを実装して「Foo」または「Dsnfdkgx」という名前を付けると、実装中に名前を付ける必要があったことがわかります。

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

基本的には、リファクタリングについてどう考えるかの問題です。個人的には気に入っていますが、実行中のシステムには絶対に触れないことを信じているチーム メイトを悩ませることもあります。そして、リファクタリングできるすべてのことの中で、名前の変更は、できる最も無害なことの 1 つです。

于 2009-01-08T09:35:01.043 に答える
3

そのクラスの適切な名前は 1 つだけです。

HelpRequest

実装の詳細が意味から気をそらさないようにしてください。

于 2009-01-08T03:44:26.587 に答える
3

HelpDocumentServiceClient のような一口、または HelpDocumentClient ではないのはなぜですか...それがベンダーであるかどうかは問題ではありません。要点は、ヘルプ ドキュメントを処理する Web サービスのクライアントです。

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

于 2009-01-07T20:41:18.140 に答える
2

私は基本に固執します:動詞名詞(引数)。例: GetDoc(docID)。

派手になる必要はありません。それがあなたであろうと他の誰かであろうと、今から1年後を理解するのは簡単です.

于 2009-01-07T20:45:19.787 に答える
2

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

于 2009-01-07T20:40:09.063 に答える
1

問題を説明するために使用する言語は、変数、メソッド、オブジェクト、クラスなどに使用する必要のある言語です。大まかに言えば、名詞はオブジェクトと一致し、動詞はメソッドと一致します。問題を説明する言葉が不足している場合は、問題の完全な理解(仕様)も不足しています。

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

疑わしい場合は、その上で寝て、翌朝、最初の最も明白な名前を選んでください:-)

ある日目を覚まして自分が間違っていることに気付いた場合は、すぐに変更してください。

ポール。

ところで:Document.fetch()はかなり明白です。

于 2009-01-07T22:39:15.593 に答える
1

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

于 2009-01-07T22:49:28.053 に答える
1

デザインパターン(GoFパターンだけでなく)は、共通の語彙を提供するための良い方法であり、状況に合わせてそれらの名前を使用する必要があることを忘れないでください。これは、命名法に精通している初心者がアーキテクチャをすばやく理解するのにも役立ちます。あなたが取り組んでいるこのクラスは、プロキシ、あるいはファサードのように機能することになっていますか?

于 2009-01-07T22:51:11.543 に答える
1

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

于 2009-01-08T00:14:07.400 に答える
1

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

于 2009-01-07T21:26:41.560 に答える
1

DocumentFetcher? 文脈なしで言うのは難しいです。

数学者のように行動し、自分のドメインの用語集を借りたり発明したりするのに役立ちます。毎回それを詳しく説明するのではなく、概念を示唆する短い平易な言葉に落ち着いてください。長いラテン語のフレーズが頭字語に変わることがよくあるので、とにかく頭字語の辞書が必要になります。

于 2009-01-07T21:54:16.823 に答える
1

これが、コーディング標準を持つ理由の 1 つです。標準を持つことは、必要に応じて名前を考え出すのに役立ちます。心を解放して、他のもっと面白いことに使うことができます。(-:

Steve McConnell の Code Complete ( Amazon リンク)の関連する章を読むことをお勧めします。

HTH

乾杯、

ロブ

于 2009-01-07T20:44:58.210 に答える
1

私は間違いなくあなたを感じます。そして、私はあなたの痛みを感じます。私が考えるすべての名前は、私にはゴミのように思えます。それはすべて非常に一般的なように見えるので、私の名前に少しの才能と創造性を注入する方法を最終的に学びたいと思っています。

私が持っている 1 つの提案は、シソーラスを参照することです。Word には、Mac OS X と同様に優れた機能があります。これは、雲から抜け出すのに本当に役立ち、良い出発点とインスピレーションを与えてくれます。

于 2009-05-30T22:47:25.480 に答える
1

命名は芸術であることに同意する必要があります。クラスが特定の「設計パターン」(ファクトリーなど)に従っている場合は、少し簡単になります。

于 2009-01-07T20:39:52.200 に答える
0

私がやっていることは、長く思い出せない場合は、長くなるかどうかを確認することです

于 2009-01-07T22:43:12.280 に答える
0

10人中8人がそれを理解していれば、それは理解可能で、読みやすく、明確であると安全に推測できます。彼らがささいなこと以外の理由であなたを失敗させようとするそれらの1つか2つのニットピッカーが常にあります。

于 2009-01-07T22:48:25.793 に答える
0

すべての賢明な名前が長すぎるか曖昧に見える場合は、少し賢明でないものを使用してみてください例:

  • クラスGoForHelpLassie
  • クラスDunnoAskTechSupport
  • クラスRTFVM[ここでVはベンダーを表します]

名前が本当に一意であり、クラスの上部に説明的なコメントがあることを確認してください。コードでそれを見る人は誰でも、それが何をするのかを調べるためにそれを調べる必要があるからです(しかし、彼らがそうするとき、彼らはおそらく覚えやすいでしょう)。

于 2009-01-07T21:20:02.913 に答える
0

何かが終わったら、名前を選ぶほうが簡単だと思います。リファクタリング->ftwの名前を変更します。

于 2009-01-08T04:45:54.683 に答える
0

あなたが .NET 開発者である場合は、BradA, Cwalina の本 - フレームワーク設計ガイドラインを読むことを強くお勧めします。そのすべてがそこで説明されています。

于 2009-01-08T11:01:40.820 に答える
0

コードを他の人が読めるようにしたい場合、これは最も重要なことの 1 つです。

わかりやすいものにするようにしてください。サードパーティの場合は、クラスまたはメソッド名に[サードパーティの]名前を含めないでください。

時間がかかる場合は、任意の名前を使用してください。後で変更できます。

于 2009-01-07T20:43:08.060 に答える
0

すべてのソフトウェア開発者がライティングとコミュニケーションのスキルを身につけなければならないもう 1 つの理由です。

PD: 豊富なボキャブラリーも重要だと思います。

于 2009-01-07T21:54:04.763 に答える
0

メソッド/クラスを「一言」で要約して、それが何を意味するのか答えてください。そして、その言葉に相当するものはないはずです。

于 2009-01-09T10:46:27.530 に答える
0

あまり。コーディングで理解しなければならないすべての難しいことを考えると、クラスとメソッドの命名がプログラミングで最も難しいことの 1 つであると言うのはばかげています。誤解しないでほしいのですが、良い名前を思いつくのは難しいこともありますが、ここでは本当のことを言いましょう。これは、プログラミングの最も簡単な部分の 1 つです。

于 2009-01-09T11:10:07.840 に答える
0

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

于 2009-01-07T20:41:45.033 に答える
0

難しいとは思いません。名前を付けられない場合は、必要ない可能性があります。デザインが優れているほど、そのデザインが行うことを簡単に挙げることができます。

さて、一時変数、それは別の話です。:)

于 2009-01-07T20:42:34.923 に答える