文法的には正しくありませんが、関数や変数などの識別子を書くときに、Yで終わる複数の単語に単に「s」を追加することは意味がありますか?この理由は、たとえば「company」を「vendor」に置き換えるなど、検索と置換が必要な場合、「company」は単数形と複数形(「company」と「company s」)の両方に一致するのに対し、複数形のスペルが正しい場合、2つの別々の検索を行う必要があります。
文法的には正しくありませんが、関数や変数などの識別子を書くときに、Yで終わる複数の単語に単に「s」を追加することは意味がありますか?この理由は、たとえば「company」を「vendor」に置き換えるなど、検索と置換が必要な場合、「company」は単数形と複数形(「company」と「company s」)の両方に一致するのに対し、複数形のスペルが正しい場合、2つの別々の検索を行う必要があります。
回答:
このような検索と置換は慎重に実行する必要があり、各変更は手動でチェックする必要があります。たとえば、コメント内の「同行」が会社/ベンダーの変更で「アベンダー」になるのを避けます。そのため、「会社」と「会社」を2回別々に検索しても、各変更の検査と承認に費やされる時間と比較して、大きなオーバーヘッドは発生しません。
したがって、1つの検索のみを実行するために単語のスペルを間違えると、見栄えが悪く、明確な利点を提供することなく、必要以上に読みにくくなるというマイナス面がもたらされます。
私はあなたがソースコードファイルの名前を変更することについて話していると仮定しています。今日のIDEでは、これは常に IDEのリファクタリングツールを使用して行う必要があります。IDEにこれがない場合は、別のIDEに切り替えることを検討してください。ほとんどのIDEリファクタリングツールはリファクタリングの履歴も保持しているため、リファクタリングの結果が気に入らない場合はすばやく「元に戻す」ことができます。検索/置換を使用すると、変更セット全体を元に戻すことができない場合があります(リビジョン管理ツールを使用して、以前にコミットしたバージョンに戻す場合を除く)。また、リファクタリングツールを使用すると、変更するつもりのないものを誤って変更することを防ぐことができます。
はい!はい!はい!それを行うことは完全に理にかなっています。そして、私は何年もそれをやっています。
開示1:英語は私の母国語ではありません。
開示2:英語の文法に関する私の知識は、平均的なネイティブスピーカーの知識よりもかなり優れています。
情報開示3:人間とのコミュニケーションについては、私は熱烈な文法ナチです。
そして、これらの開示が邪魔にならないようになりましたので、私は英語の文法がコードに場所がないことを述べさせてください。ご覧のとおり、それはコードと呼ばれ、散文ではありません。読みやすさを目的として、人間が理解する言語にいくらか類似していると思われますが、それ以外に、コードに必要なのは散文の性質ではありません。それは、精度、明確さ、簡潔さなど、他のより技術的な品質です。これが、C の構文がCobolの構文よりif( x != y ) y++;
もはるかに好ましい理由IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF.
です。自然言語を理解するコンパイラーの望ましさは間違いであり、私の言葉をその言葉に使わないでください。ol'Edsgerがそれについて何を言わなければならないかを参照してください。Edsger W. Dijkstra、「自然言語プログラミング」の愚かさについて。
重要なもう1つの品質は、識別子の計算可能性です。呼び出されたプロパティは、呼び出されColor
たメソッドを介して常に読み取られ、呼び出さgetColor()
れたメソッドを介して書き込むことができるという事実setColor()
が最も重要です。これらの識別子は、プロパティの名前から計算できるので、それらを暗記する必要はありません。プログラマーがgetColor()
一方の側で呼び出されるメソッドのペアを選択することになった場合、colorize()
他方の側では、同僚はこの妨害行為を正当に検討するでしょう。それが識別子の計算能力がいかに重要であるかです。
また、これらの名前を計算できるプログラミングツールを作成することもできます(実際には、Hibernateなどの多くのツールが作成されています)。識別子名の計算機能がない場合は、追加の構文(Hibernateなどの追加の注釈)を使用して、各ツールに、すべての単一の識別子名を正確に作成する方法、または各エンティティに指定したアドホック名を正確に指定する必要があります。
したがって、識別子の計算可能性は重要ですが、同時に英語の文法は関係がないので(自然言語プログラミングを行っていないため)、名前に常に「s」を追加してエンティティのコレクションの名前を計算できるようにします単一のインスタンスの場合は完全に理にかなっていますが、ほとんどの人(私のものを含む)の英語の感受性に違反しているという事実を気にしないでください。
そして、私たちがそれを好むと好まざるとにかかわらず、これは将来の傾向です。地球上の大多数のプログラマーの母国語は、もはや英語ではなく、この方向で非常に強い傾向が続いています。(また、私は英語が現在アメリカで働いているプログラマーの大半の母国語であるという提案にお金を賭けても構わないと思います。)これらは、名前を計算しようとするとき、大部分は「company」の単一インスタンスの名前からのコレクションの場合、「s」が追加されるだけであり、「companies」というフォームは彼らの心を交差させることさえありません。世界のますます多くの割合のプログラマーにとって、英語の特殊性についての知識は彼らの仕事に何の価値も追加せず、それをわずかに難しくするだけです。
Companys
それがあるべき時にダブルテイクのものを傷つけるつもりですCompanies
。結局のところ、私たちが普段書いているコードの要点は、実際には、自然言語に近づけることです。