命名クラスとメソッドをプログラミングの最も難しい部分の1つと思う人はいますか？
そこで、私はこのクラスに取り組んでいます。このクラスは、Webサービスを通じてベンダーにヘルプドキュメントを要求することになっています。 DocumentRetriever、VendorDocRequester、DocGetterという名前を付けようとしましたが、正しく聞こえません。結局、適切なWordを思いついて30分間 dictionary.com をブラウズしました。
悪い名前でプログラミングを開始することは、朝に非常に悪い髪の日を過ごすようなもので、残りの日はそこから下り坂になります。私を感じる？
現在あなたがしていることは問題ありません。現在の構文に固執することを強くお勧めします。
コンテキスト+動詞+方法
このメソッドを使用して、関数/メソッド、SQLストアドプロシージャなどに名前を付けます。この構文を維持することで、Intellisense /コードペインをよりきれいに保つことができます。したがって、EmployeeGetByID（）EmployeeAdd（）、EmployeeDeleteByID（）が必要です。 GetEmployee（）、AddEmployee（）などのより文法的に正しい構文を使用すると、同じクラスに複数のGetがある場合、関連のないものがグループ化されるため、これが非常に乱雑になることがわかります。
私はこれを日付の付いたファイルに名前を付けることに似ています。あなたはそれらをたくさん持った後、順序がまったく役に立たなくなるので、1-7-2009.logではなく2009-01-07.logと言いたいです。
適切な命名規則により、特定の変数、クラス、メソッド、または関数に使用できる名前の数を最小限に抑える必要があります。考えられる名前が1つしかない場合、その名前を覚えるのに問題はありません。
関数およびシングルトンクラスの場合、その基本関数がtransformある種のものから別の種のものになるかどうかを調べるために、関数を精査します。私はその用語を非常に大雑把に使用していますが、あなたが書く膨大な数の関数が本質的にある形式で何かを取り、別の形式で何かを生成することを発見するでしょう。
あなたの場合、クラスtransformsドキュメントへのURLのように聞こえます。そのように考えるのは少し奇妙ですが、完全に正しいです。このパターンを探し始めると、どこにでもそれが表示されます。
このパターンを見つけたら、常に関数に名前を付けますxFrom-y。
あなたの関数transformsドキュメントへのURLなので、私はそれに名前を付けます
DocumentFromUrl
このパターンは非常に一般的です。例えば：
atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine
注文に慣れている場合は、UrlToDocumentを使用することもできます。 xFromyまたはyTo-xと言うのはおそらく問題ですしかし、私はFrom順序を好みます。というのは、そのように関数名の先頭がすでにどのタイプを返すかを教えてくれるからです。
1つの規則を選択して、それに固執します。 xFromy関数でクラス名と同じ名前を使用するように注意している場合、どの名前を覚えているのがはるかに簡単になります中古。もちろん、このパターンはすべてに機能するわけではありませんが、「機能的」と考えることができるコードを書いている場所では機能します。
私が学んだ1つの教訓は、クラスの名前が見つからない場合、ほとんどの場合、そのクラスに何か問題があるということです。
- あなたはそれを必要としません
- やりすぎ
クラスやメソッドに適切な名前がない場合がありますが、それは私たち全員に起こります。ただし、多くの場合、名前を思い付かないことは、設計に問題があることを示唆している場合があります。あなたの方法には多くの責任がありますか？あなたのクラスは一貫したアイデアをカプセル化していますか？
スレッド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をお勧めします。
本 コード完了、スティーブマッコンネル 変数/クラス/関数/ ...の命名に関する素敵な章があります。
これは副作用だと思います。
難しいのは、実際の命名ではありません。難しいのは、ネーミングのプロセスが、あなたが何をしているのかわからないという恐ろしい事実に直面することです。
実は昨日、37Signalsの Signal vs. Noise ブログでこの引用を聞いたところ、確かにそれに同意します。
「コンピュータサイエンスには、キャッシュの無効化と命名という2つの難しいことしかありません。」 —フィル・カールトン
難しいことは良いことです。問題と、クラスが実際に行うべきことについて考えることを余儀なくされています。良い名前は、良いデザインに導くのに役立ちます。
先月、命名規則について書いていました： http://caseysoftware.com/blog/useful-naming-conventions
その要点：
verbAdjectiveNounStructure-構造と形容詞をオプションパーツとして使用
verbsの場合、アクション動詞に固執します：保存、削除、通知、更新、または生成。時々、「プロセス」を使用しますが、キューまたは作業バックログを特に参照するためだけに使用します。
nounsでは、対話するクラスまたはオブジェクトを使用します。 web2projectでは、これは多くの場合、タスクまたはプロジェクトです。ページとやり取りするJavascriptの場合、本文またはテーブルである可能性があります。ポイントは、コードが対話するオブジェクトを明確に記述することです。
structureは状況に固有であるため、オプションです。リスト画面は、リストまたは配列を要求する場合があります。 web2projectのプロジェクトリストで使用されるコア関数の1つは、単にgetProjectListです。基になるデータは変更せず、データの表現のみを変更します。
形容詞はまったく別のものです。それらは名詞の修飾子として使用されます。 getOpenProjectsのような単純なものはgetProjectsとswitchパラメーターを使用して簡単に実装できますが、これはオブジェクトの基礎となるデータや構造のかなりの理解を必要とするメソッドを生成する傾向があります。奨励します。より明示的で特定の関数を使用することで、それを使用するコードから実装を完全にラップして隠すことができます。それはオブジェクト指向のポイントの1つではありませんか？
同意した。型名と変数をできるだけ長く説明せずに長すぎるようにしたいと思いますが、良いWordを見つけることができない特定の概念がある場合があります。
その場合、同僚に入力を求めるのは常に助けになります。たとえ最終的に助けにならなくても、通常は少なくとも大声で説明して車輪を回すのに役立ちます。
要するに：
良い名前が重要であることに同意しますが、実装する前にそれらを見つける必要はないと思います。
もちろん、最初から適切な名前を付ける方が良いでしょう。ただし、2分で1つを思い付かない場合は、後で名前を変更する方が時間がかかりません。生産性の観点からは正しい選択です。
ロング：
一般に、実装する前に名前について長々と考える価値はありません。クラスを実装する場合、「Foo」または「Dsnfdkgx」という名前を付けて、実装中に名前を付けてください。
特にJava + Eclipseでは、すべてのクラスのすべての参照を慎重に処理し、名前の衝突などを警告するため、名前の変更はまったく苦労しません。クラスがまだバージョン管理リポジトリにない限り、私はしません5回名前を変更しても問題はないと思います。
基本的に、それはリファクタリングについてどう考えるかという問題です。個人的には、私はそれが好きですが、私のチームメイトは、実行中のシステムに触れないようにそして、リファクタリングできるすべてのものから、名前の変更はあなたができる最も無害なことの一つです。
クラスに名前を付けるだけでなく、適切なパッケージ構造を作成することは困難ですが、やりがいのある課題になる可能性があります。モジュールの懸念事項と、それらがアプリケーションのビジョンにどのように関係しているかを分離することを検討する必要があります。
今すぐアプリのレイアウトを検討してください。
- アプリ
- 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/ でシソーラスを使用してみてください。
それを超えて、ハンガリー記法を決して使用しないでください、略語を避けて、一貫してください。
ご多幸を祈る。
そのクラスには理にかなった名前が1つだけあります。
HelpRequest
実装の詳細が意味からあなたをそらさないようにしてください。
HelpDocumentServiceClientの種類は一口ではないのか、HelpDocumentClient ...なのか、それはベンダーであることが重要ではありません。ポイントは、ヘルプドキュメントを扱うWebサービスのクライアントであるということです。
そして、はい、ネーミングは難しいです。
私にとって、メソッドまたはクラス名がその説明的なものであり、正しいライブラリにある限り、私は気にしません。 APIの各部分がどこにあるかを覚えておくべき時代は過ぎ去りました。
Intelisenseはすべての主要言語に対応しています。したがって、サードパーティAPIを使用する場合、「実際の」ドキュメントを使用するのではなく、ドキュメントにインテリセンスを使用するのが好きです。
それを念頭に置いて、次のようなメソッド名を作成しても構いません
StevesPostOnMethodNamesBeingLongOrShort
長い-しかし、そう何。最近、24インチスクリーンを使用しない人はいますか。
優れたリファクタリングツールに投資してください！
私は基本に固執します：VerbNoun（arguments）。例：GetDoc（docID）。
派手になる必要はありません。それがあなたであるか他の誰かであるかどうか、今から1年後に理解するのは簡単です。
いいえ、デバッグは私にとって最も難しいことです！ :-)
ベンダーのドキュメントをオブジェクトにすべきではありませんか？つまり、それは具体的なものであり、プログラムの一部の擬人化としてではありません。そのため、情報を取得するコンストラクターを持つVendorDocumentationクラスがあります。クラス名に動詞が含まれていると、しばしば何かがおかしいと思う。
ネーミングは芸術であることに同意する必要があります。クラスが特定の「パターン」（工場など）に従っている場合は、少し簡単になります。
問題の説明に使用する言語は、変数、メソッド、オブジェクト、クラスなどに使用する言語です。大まかに言うと、名詞はオブジェクトに一致し、動詞はメソッドに一致します。問題を説明する言葉が欠けている場合、問題の完全な理解（仕様）も欠けています。
名前のセットから選択するだけの場合は、システムの構築に使用している規則に基づいて決定する必要があります。以前の規約で明らかにされた新しい場所に来た場合、この新しいケースをカバーするために（適切に、一貫して）拡張するために努力する価値が常にあります。
疑わしい場合は、それで寝て、最初の最も明白な名前を選んでください、翌朝:-)
ある日起きて、自分が間違っていたことに気付いたら、すぐに変えてください。
ポール。
ところで：Document.fetch（）はかなり明白です。
ローカル変数で最も問題があることがわかりました。たとえば、DocGetter型のオブジェクトを作成します。 DocGetterであることはわかっています。別の名前を付ける必要があるのはなぜですか？私は通常、dg（DocGetterの場合）またはtempまたは同様に説明のない名前を付けます。
デザインパターン（GoFパターンだけでなく）は、一般的な語彙を提供する良い方法であり、その名前は状況に応じて使用する必要があることを忘れないでください。これは、命名法に精通している新参者がアーキテクチャをすばやく理解するのに役立ちます。あなたが取り組んでいるこのクラスは、プロキシ、あるいはファサードのように振る舞うことになっていますか？
これは、コーディング標準を持つ理由の1つです。標準があると、必要なときに名前を思い付くのに役立ちます。それはあなたの心を解放して、他のもっと面白いことに使うのに役立ちます！ （-：
Steve McConnellのCode Complete（ Amazon link ）の関連する章を読むことをお勧めします。
HTH
乾杯、
ロブ
DocumentFetcher？文脈なしで言うのは難しいです。
数学者のように振る舞い、あなたのドメインのレキシコンを借りたり、発明したりするのに役立ちます：スペルのない概念をsuggest短い平易な言葉に決めます毎回それ。頭字語に変換される長いラテン語のフレーズが頻繁に表示されるため、頭字語の辞書が必要になりますとにかく。
私は間違いなくあなたを感じています。そして、あなたの痛みを感じます。私が考えるすべての名前は、私にとってはゴミのようです。それはすべてとても一般的なようで、最終的には自分の名前にちょっとした才能と創造性を注入し、彼らが本当に説明するものを反映させる方法を学びたいです。
私が持っている提案の1つは、シソーラスを調べることです。 Mac OS Xのように、Wordには良いものがあります。これは、雲から頭を出すのに非常に役立ち、良い出発点とインスピレーションを与えてくれます。
すべての賢明な名前が長すぎるか曖昧に見える場合は、少し何かを使用してみてくださいless賢明な、例えば：
- クラスGoForHelpLassie
- クラスDunnoAskTechSupport
- クラスRTFVM [Vはベンダー用]
名前が実際に一意であり、クラスの先頭に説明的なコメントがあることを確認してください。コード内でそれを見る人は誰でもそれを調べて何をするのか調べる必要があります（しかし、そうすることで、覚えやすくなるでしょう。
名前が素人プログラマーに説明するなら、おそらくそれを変更する必要はないでしょう。
私がやることは、長く思い出せない場合、それが長いかどうかを確認することです
難しいとは思いません。名前を付けられない場合は、必要ないかもしれません。デザインが優れているほど、デザインが行うことを簡単に命名できます。
一時変数。これは別の話です。 :)
コードを他の人が読めるようにする場合の最も重要なことの1つです。
それを説明的にしようとし、それがサードパーティのものである場合、クラス名またはメソッド名に[サードパーティの]名前を含めないでください。
時間がかかる場合は、任意の名前を使用してください。あとで変更できます。
10人中8人がそれを理解している場合、それは理解可能で、読みやすく、明確であると安全に想定できます。それらがささいであるということ以外の理由であなたを非難しようとするそれらの1つまたは2つのニットピッカーが常にあります。
何かが終わったら名前を選択する方が簡単だと思います。リファクタリング-> ftwの名前変更。
すべてのソフトウェア開発者がライティングとコミュニケーションのスキルを持つ必要があるもう1つの理由。
PD：膨大な語彙も重要だと思います。
メソッド/クラスを「ワンワード」で要約し、それが何を意味するのかを答えてください。そして、その言葉に相当するものはないはずです。
あなたの痛みが分かります。 ：/
データディクショナリ（さまざまな変数/メソッド名を記述したファイル、私はjavadocのようなものだと思う）とともにソースコードをレビューするツールがあればいいのに、次のようなコードを書くことができます。
class Battery
{
double I; // current
double T; // temperature
double V; // voltage
double Q; // charge
void update(double Inew, double dt) { I = Inew; Q += I*dt; }
// ... etc ...
};
また、コードレビューツールは、I =現在のリマインダーを表示するなど、コンテキスト内のコードを簡単に表示するためにさまざまなことを行うことができます（たとえば、ウィンドウの右側のペインに変数定義を表示します） /クリックしたコード内の場所の/ semantics/comments）、または「仮想リファクタリング」を実行できるようにしますディスク。
自己記述的な名前が好きな限り、BatteryFilteredCurrentInMilliampsのようなものを読むのは嫌いです。多くの場合、組み込みシステムでは代数方程式に基づいてオブジェクトをモデル化し、方程式のような名前は非常に扱いにくくなります。 （一方、帽子が上にあり、下付き文字が「d」、上付き文字が「*」の「I」はやや紛らわしい。）
私は最初に軽微なソフトウェアの責任を持つEE /システムエンジニアであり、最終的には変数が何であるかを伝え、それを自分の内部モデルにマッピングする便利な方法がある限り、変数の名前は気にしません制御されているシステムの。
それは通常私にとって非常に自然に感じます。私は常に非常に短いメソッドを作成し、Smalltalkコードは6行を超えない（自動フォーマット）ため、このメソッドが何であるかを言うのに問題はありません。
選択したいWordがシステムのどこかで使用されているため、クラス名が難しい場合があります。同じWordが異なるコンテキストで異なる意味を持つ場合があるためです。そのような場合、Wikipediaに似た構文が許可されることを望み、クラスに「タスク（リスト項目を実行する）」という名前を付けることができます。それが合法になるまで、私は大きなドイツ風のWordを作ります：ToDoListItemTask。ご想像のとおり、メソッド名も非常に長くなる可能性があります。しかし、それらは読みやすいと思います。
したがって、あなたの場合、あなたのクラスは「ゲッター」、またはレトリーバー、または何でもです。これはクラスでモデル化する必要がありますか？むしろベンダーのドキュメントはそれ自体を要求できるべきではありませんか？ vendorDoc.requestFrom（source）;のようなもの簡単に名前を付けられると思いませんか？
乾杯、
ニコ
あんまり。コーディングで理解しなければならないすべての難しいことを考えて、クラスとメソッドの命名はプログラミングで最も難しいことの1つであると言うのはばかげています。誤解しないでください。良い名前を考えるのは難しいこともありますが、ここで本物になりましょう。私は、これがプログラミングの最も簡単な部分の1つであると言うまでに行きます。