ソースコードのスペルミスが深刻な問題であるかどうかを確認する方法は？
私のコードベースで毎日目にする非常に厄介なスペルミスを見つけました。そこから、非常に短いが代表的な例を再現します。
ArgumnetCount
Timeount
Gor message from queue
残念ながら、これは決して一人に限定されません。私たちのチームには、ネイティブでない英語を話す人がたくさんいますが、アメリカ人で生まれ育った私たちのソフトウェアアーキテクトに、最悪のスペルミスをいくつか指摘することもできます。
これらは、電子メール、プレゼンテーション、ドキュメントなど、ソフトウェア開発会社にある書面のあらゆる情報にも見られます。
深刻な問題かどうかを確認する方法を教えてください。
私は常に心配してこれらのスペルミスに遭遇しましたが、私自身の個人的なポリシーofficialは、スペルを正しくするために報酬が支払われるのではなく、物事を完了するために報酬が支払われるので、社内では私はそれについて誰かを本当に批判したことはありません。しかし、私は親しい友人の何人かとこの問題を提起しました、そしてそれを永遠に解決したことはありません。
スペルエラーは、次の2つのいずれかを意味します。
- それらを作成する人は英語に堪能ではなく、適切なツール（辞書、スペルチェッカーなど）を使用して補うために時間をかけません。
- それらを作る人は英語に堪能ですが、綴りはまったく気にしません。
どちらもかなり悪い兆候です。それは、問題の人が優先度リストで高い可読性、保守性、優雅さを備えていないことを意味するためです。原因が英語の熟練度の欠如である場合、その人には2つの基本的なスキルが欠けていることも意味します-書かれた英語のコミュニケーションと言語に対する一般的な感覚（英語で考えを明確に表現できない場合、可能性はあるでしょう） tは、プログラミング言語でも十分に表現できます）。
しかし、なぜスペルエラーが正確で、他のすべてが等しいのですか？結局のところ、コードは機能し、コンパイラは構文規則に違反しない限り、識別子に名前を付ける方法をまったく気にしません。その理由は、コンピュータだけでなく人間向けのコードも作成しているためです。そうでない場合でも、Assemblyを使用します。ソースコードは1回だけ作成されますが、そのライフサイクル中に何百回も読み取られます。スペルミスがあると、ソースコードの読み取りと理解が難しくなります。軽度のエラーにより、リーダーがほんの一瞬でつまずき、多くの場合、かなりの遅延が発生します。本当に悪いエラーはソースコードを完全に読めなくする可能性があります。別の問題もあります。これは、作成したコードのほとんどが他のコードによって参照され、そのコードが他の誰かによって書かれることが多いということです。識別子のスペルを間違えると、他の誰かが名前が何であるかだけでなく、スペルの正確さも覚えている（または調べる）必要があります。これには時間がかかり、プログラミングフローが中断されます。また、ほとんどのコードはメンテナンス中に2回以上変更されるため、スペルミスが発生するたびに中断が発生します。
開発者の時間と給与が経費とどのように等しいかを考えてみてください。これは簡単に説明できるはずです。結局のところ、フローを中断してそこに戻るには、最大15分かかる場合があります。このように、深刻なスペルミスは、その後の開発とメンテナンスに数百ドルの費用がかかる可能性があります（ただし、これらは間接的なコストであり、見積もりや評価に直接表示されないため、経営者によって無視されることがよくあります）。
「Timeount」がネイティブスピーカーでないことが問題なのかどうか、私は実際に疑っています。人々は母国語でたくさんのタイプミスをします。私はこれらの特定の例を「英語」とは見なしません。
そうは言っても、私はそれがこれらの特定の例についてではないことを理解しています。原則として同意します。この種の問題が原因で実際に問題が発生しました（「attachmentsという名前の列がない場合は、添付ファイルを作成してください」）。
プログラマーであることは、タイプミス、コンマ、セミコロン、ドットを正確かつ注意深く行うことであり、ほとんどの場合、人間の言語に依存しません。
この問題が気になる場合は、ほとんどのIDEでコメントのスペルチェックを許可して、失読症者が少なくとも綴り方を知っているように見えるようになりました。それは確かに私に役立ちます！したがって、それは簡単な「修正」です。スペルを正しくする。
パブリッククラスの名前とメソッドのスペルミスは、専門外です。彼らは時間とお金がかかります。 IDEはクラス名とメソッド名のメニューを生成できるため、Javaなどの静的型付け言語では苦痛です。動的型付け言語では耐えられません。
さらに悪いのは、データベーステーブル名と列名のスペルミスです。
私の経験では、正しいスペルは、コーダーの英語力とわずかに関連しています。私はネイティブスピーカーが本質的にランダムなスペルとワードブレークを使用してコードを生成するのを見てきました。また、ネイティブスピーカー以外のネイティブスピーカーが正しいスペルを慎重に生成するのを見てきました。ただし、正しいスペルは、全体的なコード品質に大きく関係しています。有能なプログラマーは、英語の能力に関係なく、仕事の質を気にし、ネーミングに注意を払います。
ソースコード、内部プレゼンテーション、ドキュメントなど、意味を変えたり理解を妨げたりしない小さなタイプミスは問題ではありません。あなたがそれらがいらいらするのを見つけた場合は、ソースでそれらを修正してください。
また、特にコメントでは、フォームよりも実体の方が重要です。ここに英語はありません：
文字列s = "Wikipedia";/*変数sに値「Wikipedia」を割り当てます。 * /
実際のところ、一部の人々は他の人よりもより慎重な作家です（これが教育のためか、態度のためか、または知性などのため、関係ありません）。これを修正するためにどれだけの労力を費やすことがビジネス価値の問題です。タイプミスを修正するよりも、タイプミスを修正する方がより多くの価値を得られますか？内部的なものの場合、答えは通常ノーです。顧客は、ソースコードのコメントのタイプミスについて不満を言うことはありません（オープンソースを使用している場合を除きます）。
意図的なタイプミスや不適切なコメントは専門的ではないため、避ける必要がありますが、重要なことに焦点を当てる必要があります（つまり、ビジネスで働く場合にビジネス価値を生み出す）。
もちろん、公開されているものは注意深く校正する必要があります。
ここでの問題は、英語そのものではなく、コメントの明確さの欠如です。完璧な英語は必要ありません、明確な英語が必要です。明らかなエラーを拾うためにグーグルを介して何かを実行するのは簡単です。
たとえば、Gor message from queueは、「キューからメッセージを取得」または「キューからGORメッセージ」を意味します。コメントの意味を理解するには、コードを読む必要があります（したがって、コメントのオブジェクトを無効にします）。
あなたの会社でコードレビューを実装するように依頼する必要があります。そうすれば、建設的に人を「批判」することができます。
同じスペルを使用している限り、コンパイラはスペルミスを気にしないことは明らかです。変数を参照するとき。次に、スペルミスがチームメンバーのコードを維持する能力に悪影響を及ぼすかどうかが問題になります。
私がそうするために私が見ることができる唯一の方法は、メンテナンスをしている人々と話すことです、そしてあなたは誰かがミススペルを含んでいるコードを追うのに苦労したかどうか尋ねることから始めることができます。
この問題から主観性を完全に取り除く方法はないと思いますが、それを減らすために、（手動またはスクリプトを介して）ソースをスキャンして、特定のコードモジュールのスペルミスの推定数を取得し、メンテナンスを確認できますスペルミスの数が多いモジュールでは、スペルミスの数が少ないモジュールよりも平均で時間がかかりました。
もちろん、すべてのモジュールが同等に作成されているわけではないので、モジュールの循環的複雑度などのさまざまなメトリックで結果に重みを付けることを考えることができます。
私の経験では、このような基本的なスペルミスは厄介であり、より深い問題の兆候である可能性があります。私が取り組んだすべてのプロジェクトは、設計中に本当の問題があり、レビュープロセスを通じて開発中にのみ作成されたnotを知りたいときに、設計に実際の問題があったような「些細な」エラーで取り組みましたあなたが本当に必要とする重要な機能がそこにないこと。
システムの仕様（存在する場合）を再確認し、全体的な設計を調べます。あなたがいくつかの穴を見つけたとしても、私は驚かないでしょう。
これは実際には2つの別々ですが、関連する問題です。スペルミスの場所によって異なります。
1）ソースコード内。 ArgumnetCountのような識別子がある場合、誰かがやって来て正しいスペルを使用すると、実際の問題が発生する可能性があります。したがって、可能な場合はいつでもこれらの間違いを修正する必要があります。 APIの下位互換性を維持する必要がある場合は、次のようなことができます。
/**
* @deprecated - use setArgumentCount()
*/
public void setArgumnetCount(int c) {
setArgumentCount(c);
}
2）人間が読めるテキスト（メール、ドキュメント、コードコメント）。それらを正しく書くことは重要ですが、頭の中にある構文解析ソフトウェアの方がはるかに寛容なので、優先度は低いと思います。いくつかの間違いのあるテキストが表示されても、それはまだ読めるので、心配しないでください。それはあなたの問題ではありません。しかし、誰かがあなたにいくつかの自由連想ナンセンスを送って、あなたがマルチユーザーWebアプリケーションの青写真としてそのナンセンスを使用することを期待するなら、あなたは説明を要求する丁寧なメモを作者に送るべきです：あなたは私がこのたわごとを理解することを期待しますか？」）