識別子で「ies」の代わりに「ys」を使用して、検索および置換機能を容易にすることは理にかなっていますか?[閉まっている]


9

文法的には正しくありませんが、関数や変数などの識別子を書くときに、Yで終わる複数の単語に単に「s」を追加することは意味がありますか?この理由は、たとえば「company」を「vendor」に置き換えるなど、検索と置換が必要な場合、「company」は単数形と複数形(「company」と「company s」)の両方に一致するのに対し、複数形のスペルが正しい場合、2つの別々の検索を行う必要があります。


8
子供、ネズミ、ナイフ、オオカミ、男性、女性、妻、歯はどうですか?恐ろしい「2つの個別の検索」を回避するために、すべてが有効です。
TulainsCórdova15年

3
私はウルフィーよりも自分自身にウルフィーに部分的です...
ジミーホッファ

2
ワークフローで非常に頻繁に識別子の名前を変更する予定ですか?これまで使用されていない可能性のある関数をサポートするためだけに、コード内のスペルミスのある名前のすべての認識の奇妙さを引き受けることは少しやり過ぎです。
ケントA.

10
私を信じて、「フルワードのみ」の制約なしに「company」のようなワードの大きなコードベースに対して検索と置換操作を適用したくないのです。したがって、2つの別々の検索を使用する必要があります。
Doc Brown

2
二。分ける。検索。
TulainsCórdova15年

回答:


24

このような検索と置換は慎重に実行する必要があり、各変更は手動でチェックする必要があります。たとえば、コメント内の「同行」が会社/ベンダーの変更で「アベンダー」になるのを避けます。そのため、「会社」と「会社」を2回別々に検索しても、各変更の検査と承認に費やされる時間と比較して、大きなオーバーヘッドは発生しません。

したがって、1つの検索のみを実行するために単語のスペルを間違えると、見栄えが悪く、明確な利点を提供することなく、必要以上に読みにくくなるというマイナス面がもたらされます。


11
また、リファクタリングツールが改善されるにつれて、テキストのみに基づいたグローバルな検索と置換は、識別子の名前を変更するための最も信頼性の低い方法になりつつあります。
ケントA.

Doc Brownが述べたように、これは「単語のみ」の検索を使用した問題ではありません。
SHNC、2015

6
@ user3047082、単語全体の検索も「companys」と一致せず、質問全体がかなり無意味になります...
David Arno

6

私はあなたがソースコードファイルの名前を変更することについて話していると仮定しています。今日のIDEでは、これは常に IDEのリファクタリングツールを使用して行う必要あります。IDEにこれがない場合は、別のIDEに切り替えることを検討してください。ほとんどのIDEリファクタリングツールはリファクタリングの履歴も保持しているため、リファクタリングの結果が気に入らない場合はすばやく「元に戻す」ことができます。検索/置換を使用すると、変更セット全体を元に戻すことができない場合があります(リビジョン管理ツールを使用して、以前にコミットしたバージョンに戻す場合を除く)。また、リファクタリングツールを使用すると、変更するつもりのないものを誤って変更することを防ぐことができます。


3
この回答に低品質のフラグを付けた人には、質問どおりに厳密に回答することはできませんが、そのような命名スキームを使用する理由の全体像と、同じタスクを実行するためのより良い方法が示されます。フラグレビューに「OKのように見える」と投票し、賛成票を追加しました。

ありがとう、@ Snowman。未知の領域にいるとき、自分の(経験の浅い)考え方に基づいて質問を組み立てることは人間の本性です。はい、実際の質問には答えませんでしたが、実際に質問されていることについての私の仮定は、質問の他の手がかりに基づいていました。私が最も遭遇した複数形は、XSD-to-POJO、データベースからのHibernate / JPAリバースエンジニアリングなどのコード生成ツールからのものです。基本的に、これらの複数形がコード内にあり、作者が選択を好まなかった場合複数形の場合は、おそらく著者が作成したものではなく、自動生成された可能性が高いです。
javabeano

-9

はい!はい!はい!それを行うことは完全に理にかなっています。そして、私は何年もそれをやっています。

開示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」というフォームは彼らの心を交差させることさえありません。世界のますます多くの割合のプログラマーにとって、英語の特殊性についての知識は彼らの仕事に何の価値も追加せず、それをわずかに難しくするだけです。


7
1.インデックスとインデックスはどちらも有効なインデックスの複数形です。正しいのは1つだけだと誤解されています。たとえば、oxforddictionaries.com/definition/english/indexをご覧ください。2. getX経由で読み取り、setX経由で書き込むことができるプライベートXはプライベートではありません。それは公共の価値です。3.コードは設計ドキュメントです。「マシンコード」の生成方法をコンパイラーに通知しますが、さらに重要なこととして、他の人が簡単に読み取れるようにその設計を記述します。読みやすさは、コードの2つの最も重要な側面の1つです(テスト可能性はもう1つです)。
David Arno

3
コードは、2つの理由で書かれています。人間が読み取るため、およびコンピュータが実行するためです。ソースコードはに人間が読むために書かれていると言う人もいます。そのほとんどは、コンピューターが実行する前にすぐにバイトコードにコンパイルされるからです。したがって、コンピュータは適切な文法を気にしないかもしれませんが、人間は確かにそうします。
エリックキング

3
英語はあなたの母国語ではないかもしれませんが、あなたのコードを読むのは次の人かもしれません。それはおそらく英語を学んだあなたの母国語の他のものも混乱させるでしょう。
アンディ

2
またはあなたがCompanysそれがあるべき時にダブルテイクのものを傷つけるつもりですCompanies。結局のところ、私たちが普段書いているコードの要点は、実際には、自然言語に近づけることです。
アンディ

2
とにかく、私はその紙がたわごとでいっぱいだと思います。コードは自然言語とバイトコードの間にあります。コードに対する人間の理解を容易にするためでなければ、バイトコードを直接入力するだけの理由はありません。
アンディ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.