ソースコードのスペルミスが深刻な問題であるかどうかを調べる方法 [閉まっている]

コードベースには毎日非常に厄介なスペルミスがありますが、ここから非常に短いが代表的な例を再現します。

ArgumnetCount
Timeount
Gor message from queue 

残念ながら、これは決して一人に限定されません。私たちのチームにはこれに貢献する英語を母国語としない人がたくさんいますが、私はアメリカ人で生まれ育ったソフトウェアアーキテクトに最悪のスペルミスのいくつかを特定することもできます。

これらは、電子メール、プレゼンテーション、ドキュメントなど、ソフトウェア開発会社で書かれた情報のあらゆる部分にも見られます。

それが深刻な問題かどうかを調べる方法を知りたいですか？

_{私は常にこれらのスペルミスに懸念を抱きましたが、私自身の個人的な公式ポリシーは、私たちは正しいことをするためにお金を払わないこと、物事を成し遂げるためにお金を払うことであるので、会社の中で私はそれについて誰も本当に批判しませんでした。しかし、私は親しい友人の何人かとこの問題を提起しました、そして、それを永久に解決しませんでした。}

スペルミスは、次の2つのいずれかを意味します。

• それらを作成する人は英語に堪能ではなく、適切なツール（辞書、スペルチェッカーなど）を使用して補うために時間をかけません
• それらを作成する人は英語が堪能ですが、スペルはまったく気にしません。

どちらもかなり悪い兆候です。これは、問題の人が優先度リストで高い読みやすさ、保守性、優雅さを持たないことを意味するためです。原因が英語能力の欠如である場合、それはまた、その人は2つの不可欠なスキルを欠いていることを意味します-英語で書かれたコミュニケーションと言語に対する一般的な感覚プログラミング言語でうまく表現できます）。

しかし、なぜスペルミスは正確に悪いのですか？結局のところ、コードは機能し、コンパイラは識別子が構文規則に違反しない限り、識別子の命名方法をまったく気にしません。その理由は、コンピューターだけでなく、何よりも人間のためにコードを書くからです。そうでない場合は、アセンブリを使用します。ソースコードは一度書かれますが、そのライフサイクル中に何百回も読み込まれます。スペルミスは、ソースコードの読み取りと理解を難しくします。軽度のエラーは、読者をほんの一瞬つまずかせます。それらの多くは、かなりの遅延を引き起こす可能性があります。本当に悪いエラーは、ソースコードを完全に読めなくする可能性があります。別の問題があります。それは、あなたが書いたコードの大部分が他のコードによって参照され、そのコードが他の誰かによって書かれていることが多いということです。識別子のスペルを間違えた場合、他の誰かが名前が何であるかだけでなく、スペルがどれだけ正確であるかを覚える（または調べる）必要があります。これには時間がかかり、プログラミングフローが中断されます。また、ほとんどのコードはメンテナンス中に複数回変更されるため、各スペルミスにより多くの中断が発生します。

開発者の時間と給料と経費の関係を考えてみてください。このことを主張するのは十分簡単だと思います。結局、フローを中断して元に戻るには最大15分かかります。このように、重大なスペルミスは、さらなる開発と保守に数百ドルを簡単に費やす可能性があります（ただし、それらは間接的なコストであり、見積もりや評価に直接表示されないため、多くの場合経営陣によって無視されます）。

「Timeount」がネイティブスピーカーではないかどうかは実際には疑問です。人々は母国語でたくさんのタイプミスをします。これらの特定の例を「Engrish」とは見なしません。

そうは言っても、これらの特定の例に関するものではないことを理解しています。私は原則としてあなたに同意します。この種のものによって引き起こされる実際のトラブルに遭遇しました（「attachementsという名前の列がない場合、添付ファイルを作成する」）。

プログラマーになるには、タイプミス、コンマ、セミコロン、ドットを正確かつ慎重に扱う必要があります。これはほとんどの場合、人間の言語に依存しません。

Timeout変数を検索するために時間を無駄にしたのはTimeount、それがとして書かれていることを知るためだけです。スペルが重要である別の理由がわかります。

この問題に悩まされている場合、ほとんどのIDEではコメントのスペルチェックが許可されているため、ディスレクシアは少なくともスペルの方法を知っているように見えます。それは確かに私を助けます！したがって、正しいスペルを使用するのは簡単な「修正」です。

パブリッククラスの名前とメソッドのスペルミスは、単に専門的ではありません。時間とお金がかかります。IDEはクラス名とメソッド名のメニューを生成できるJavaのような静的に型付けされた言語では苦痛を伴います。動的に型付けされた言語では耐えられません。

さらに悪いのは、データベースのテーブル名と列名のスペルミスです。

私の経験では、正しいスペルはコーダーの英語能力にわずかに関連しています。私は、ネイティブの英語を話す人が本質的にランダムなつづりと単語の区切りでコードを生成するのを見てきました。ただし、正しいスペルは全体的なコード品質に大きく関係しています。有能なプログラマーは、英語力に関係なく、自分の仕事の質を気にし、ネーミングに注意を払っています。

ソースコード、内部プレゼンテーション、ドキュメントなどでは、意味を変えたり理解を妨げたりしない小さなタイプミスは問題ではありません。刺激がある場合は、ソースで修正してください。

また、特にコメントでは、実体はフォームよりも重要です。ここに英語はありません：

文字列s = "Wikipedia"; / *値「Wikipedia」を変数sに割り当てます。* /

事実、一部の人々は他の人々よりも自然に慎重な作家であるということです（これは教育によるものか、態度によるものか、知性などによるものかは関係ありません）。それを修正するためにどれだけの労力を費やすかはビジネス価値の問題です。タイプミスを修正することで、タイプミスを修正することに努力するよりも多くの価値を得ることができますか？内部的なものの場合、答えは通常ノーです。あなたの顧客はあなたのソースコードのコメントのタイプミスについて文句を言うつもりはありません（あなたがオープンソースをしているのでなければ）。

意図的な入力ミスや不適切なコメントは専門家ではないため避けるべきですが、重要なことに焦点を当てる必要があります（つまり、ビジネスで働いている場合、ビジネス価値を生み出す）。

もちろん、公開されているものは慎重に校正する必要があります。

ここでの問題は、エングリッシュ自体ではなく、コメントの明確性の欠如です。完璧な英語は必要ありません、明確な英語は必要です。明らかなエラーを拾うためにグーグルを介して何かを実行するのは簡単です。

たとえばGor message from queue、「キューからメッセージを取得した」または「キューからのGORメッセージ」を意味する場合、一目でわかりません。コメントの意味を理解するには、コードを読む必要があります（したがって、コメントのオブジェクトを無効にします）。

会社にコードレビューを実装するよう依頼する必要があります。そうすれば、人々はあなたに対して同じことをしながら、建設的な方法で人々を「批判」することができます。

変数を参照するときなど、同じスペルを使用している限り、コンパイラはスペルミスを気にしないことは明らかです。問題は、つづりの間違いがコードを維持するチームメンバーの能力に悪影響を与えるかどうかになります。

私がそれを確認できる唯一の方法は、メンテナンスを行っている人と話をすることです。スペルミスを含むコードを追跡するのに苦労している人がいるかどうかを尋ねることから始めることができます。

この問題から主観性を完全に取り除く方法はないと思いますが、それを減らすために、（手動またはスクリプトを使用して）ソースをスキャンして、特定のコードモジュールのミススペルの推定数を取得し、メンテナンスの有無を確認することができますミススペルの数が多いモジュールでは、ミススペルの少ないモジュールよりも平均して時間がかかりました。

もちろん、すべてのモジュールが等しくなるわけではないので、モジュールの循環的な複雑さなどのさまざまなメトリックで結果を重み付けすることを考えることができます。

私の経験では、そのような基本的なスペルミスは厄介であり、より深い問題の徴候であるかもしれません。このような「些細な」エラーで取り組んだすべてのプロジェクトには、設計中に実際の問題があり、レビュープロセスを経て開発中に切り出されるだけでしたが、本当に必要な重要な機能を見つけることはできませんありません。

システムの仕様（存在する場合）を再確認し、全体的な設計を調べます。あなたがいくつかの穴を見つけても私は驚かないでしょう。

これは実際には2つの別個の問題ですが、関連する問題です。スペルミスの場所によって異なります。

1）ソースコード内。のような識別子がある場合ArgumnetCount、誰かが来て正しいスペルを使用すると、実際の問題が発生する可能性があります。そのため、可能な限りこれらの間違いを修正する必要があります。APIの後方互換性を維持する必要がある場合は、次のようなことができます。

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2）人間が読めるテキスト（電子メール、ドキュメント、コードコメント）。それらを正しく記述することは重要ですが、頭の中の解析ソフトウェアははるかに寛容なので、優先度は低いと思います。いくつかの間違いのあるテキストが表示されても、それはまだ読みやすいので、心配する必要はありません-それはあなたの問題ではありません。しかし、誰かがあなたに自由連想のナンセンスを送って、そのナンセンスをマルチユーザーWebアプリケーションの設計図として使用することを期待している場合、明確化を要求する丁寧なメモを著者に送信する必要があります（あなたは私がこのたわごとを理解することを期待していますか？」）

正しいスペルの英語はコードで必須です。私はまた、その中にぎくしゃくした完全な大規模なコードベースがあり、それを維持するのは悪夢です。

これを手に負えないようにしてください。コード保守担当者は読者ではないことを全員に教育してください。

さて、これは多面的な文化的問題です。

ドイツの観点から言えば、私たちは自分の言語が英語の用語からますます影響を受けていることに気づきます。これは、国内企業が英語のスローガンや広告を持っている限りです。一部の人々、特に管理職では、明らかに一言のドイツ語で発言することはできません。彼らのスピーチは話題の言葉と理解できない管理スラングに満ちています。私たちは、そのような人は「英語」と言っていると言います。

このような状況と英語が特にソフトウェアビジネスの「共通語」であることを考えると、英語そのものが膨大な数の非ネイティブスピーカーの影響を受けることは避けられません。しかし、英語のネイティブスピーカーにとっては、これはSW業界に参加するために、たとえば中国語を学習するよりも優れています。

それは色ですか色ですか？誰のバージョン英語のか、あなたが正しいものであると思いますか？ある人の正しい綴りは、別の人が勝つことができる戦争を開始する言い訳です。

戦争を始めたい場合は、慎重に戦いを選び、勝利してください。あなたの場合、コメントについては心配せず、内部についてはあまり心配せず、APIのみに（ほぼ）焦点を合わせてください

私は格言を持っています：きちんとしたコードは必ずしもきちんとした心を意味するわけではありませんが、表側は確かに真実です：きちんとしたコード、きちんとした心。

変数に名前を付けたり、コメントを正しく綴ったりするのに時間をかけないプログラマーは、他のことを正しく行うのに時間をかけないことはほぼ確実です。プログラマーがネイティブスピーカーであるかどうかは実際の問題ではありません。なぜなら、彼の英語の問題は、ピアレビュー中に対処できるからです。

はい、それは製品、チーム、そして個人にとって深刻な問題です。

• 製品の場合：修正により、顧客のみがキャッチする欠陥が発生する場合があります
• チームにとって：チームは価値を生み出すのではなく、ずさんなコーディングの修正に時間を費やします
• 個人の場合：スペルが間違っていると、あなたは愚かに見えるようになり、同僚間の専門的な地位が低下します。