メソッド名と関数名の「A」、「an」、「the」：あなたはどう思いますか？[閉まっている]

私たちの多くは、このようなメソッド名を見たことがあります。

• UploadTheFileToTheServerPlease
• CreateATemporaryFile
• WriteTheRecordToTheDatabase
• ResetTheSystemClock

つまり、文法的にも正しい英語の文であり、純粋に散文のように読めるように余分な単語を含むメソッド名。個人的には、私はそのような「リテラル」メソッド名の大ファンではなく、できる限り明確でありながら、簡潔であることを好みます。私にとって、 "a"、 "an"、および "the"のような単語は、メソッド名では単純に不自然に見えるだけで、有用なものを追加することなく、メソッド名を不必要に長くします。前の例では、次のメソッド名を使用します。

• UploadFileToServer
• CreateTemporaryFile
• WriteOutRecord
• ResetSystemClock

私の経験では、これはより長い名前を書き出す他のアプローチよりもはるかに一般的ですが、私は両方のスタイルを見て、これら2つのアプローチに対する他の人々の考えを知りたいと思っていました。

だから、あなたは「散文のように読めるメソッド名」キャンプか「悪い意味の外国語から英語への翻訳のように大声で読むメソッド名」キャンプにいますか？

私は、散文メソッドが1つの例外を除いて吸うことに同意します。

ユニットテストケース

通常、これらはコードで呼び出されることはなく、テストレポートに表示されます。そのため、もう少し散文を付けて読み出しを行うと便利です。

• AddedACustomerOrderFailWhenCustomersIdIsInvalid：失敗
• OutOfBoundsPriceReturnsAnError：合格
• CanDeleteAnEventFromASeason：合格

これも控えめに行う必要がありますが、文法的な追加により、合格したものと失敗したものを表現するのが少し簡単になる少なくとも1つのケースとして見ることができます。もちろん、あなたの言語/フレームワークがメソッド名以外のテスト記述のテスト記述のための優れたメカニズムを提供しない限り、これは無視されます。

オフィススペースからローレンスを言い換えると...

いや、いや、この辺で働いていた誰かが 'UploadTheFileToTheServerPlease'という関数を名付けたら、彼は彼を蹴り飛ばしたと信じています。

そのような「長い」名前は散文のようには聞こえません。単独の場合-おそらく、残りのコードを伴って、彼らは単に混乱を起こします。見てみな：

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk！..

これは有効な英語のテキストではなく、どのプログラミング言語でも1つのようには見えません。したがって、記事にバイトを費やす意味はありません。

プログラマーの観点からすると、「UploadFileToServer」は「UploadTheFileToTheServerPlease」よりも読みやすく、理解しやすいものです。

プログラミングでは、英語の文法、読みやすさ、理解しやすさよりも重要です！

私の人生がどのくらいのタイプミスを抱えているかを考えると、

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

まじめな話、クラス名も見てみました。クラスが「ファイル」と呼ばれる場合、おそらく次のようになります。

*UploadToServer
*DownloadFromServer

だからそれは

   File file = new file;
   file.UploadtoServer(ServerAddress);

ほんの些細な例ですが、うまくいけばそれで十分に説明できます。

個人的には気にしません。私はそれらを見てきましたが、彼らは私を悩ませません。別のプログラマーが彼らについて大声で叫ぶまで、私はそれらについてさえ考えませんでした。誰かがあまり重要ではないことをあまり気にしないのは衝撃的でした。彼は実際にそれについて怒っていたということです。しかし、それは約11年前の私のキャリアの早い時期であり、それ以来、開発者が些細なことに怒っていることは実際には非常に一般的であることがわかりました。開発者のマネージャーがこれほどうまく報酬を得るのはこのためです。彼らは毎日開発者に対処しなければなりません。

そして、「UL_FlToSrv」よりもむしろそれを見たいと思います。