誰かのコードのスペル/文法関連の間違いを指摘すべきですか？[閉まっている]

同僚のコードを確認しているときに、関数名のスペルミスや、関数名と変数名の「doesUserHavePermission（）」ではなく「doesUserHasPermission（）」のような文法エラーに遭遇しました。

これらを彼に指摘する必要がありますか？

スペルミスと文法エラーのあるコードは維持できません。

• 人々は悪い文法を覚えていないので、書かれていたはずの関数を呼び出そうとします。それがバグの発生方法です。

• コードのつづりがわからない場合、コード内の何かをgrepできません。

• 文法/綴りを作るほとんどの人はそう一貫しないので、命名が一致しない多くのバグを導入します。これは、使用前に変数を明示的に宣言する必要のない言語では特に問題となります。新しいスペルを導入でき、コードが失敗したことを知らせるためにコードが中断することがないためです。

これらの問題を修正することは、教訓的ではありません。また、主に他の人の知性、リテラシーなどの意見によって必要とされることもありません（それは大きな副作用です）。それは、高品質で保守可能なコードを記述することです。

はい、間違いなく。名前が文法的に正しい場合、名前を覚える方が簡単です。名前と文法の間違いを思い出そうとすることは、まったく別のことです。

正式なコードレビューの欠陥として指摘しないでください。代わりに、リストをマークアップして、プライベートに彼/彼女と話してください。「ねえ、私は気づいたこと、そしてこの種のことを本当に軽lookしている人々に出会ったので、プログラマは不注意でずさんなように見えると思う」と、それについてできるだけ外交的にしてください。

これが顧客に表示されるコードである場合、絶対に修正する必要があります。好むと好まざるとにかかわらず、それはあなたの会社の評判を反映しています。

あなたが与えた例では、私はそれがUserHasPermissionとして始まったのではないかと疑っています、そして他の誰かがローカル練習はUserBlahBlah（）ではなくdosUserBlahBlah（）であると彼に言いました、そして彼は文法の変更を見落としました。

自分で変更してください。

コードの「所有権」が問題にならない環境にいることを願っています。ソース管理でプロジェクトにアクセスできる場合は、自分で修正してください。特定の同僚が同じタイプの文法やスペルミスを一貫して犯しているのを見たら、それを指摘したいかもしれませんが、それはあなたの関係、その人がネイティブの英語話者であるかどうか、そして彼らの一般的な受容性に依存します。しかし、あなたがそれをすることにしたかどうかにかかわらず、静かに行って修正を行ってください。特にメソッドシグネチャまたはパブリックプロパティでタイプミスを見つけた場合は、常にこれを実行します。時々、コメントのタイプミスを修正する誘惑に抵抗することさえできませんが、それは私だけです:)

私はネイティブ言語が英語ではなく、実際はオランダ語である開発者であり、誰かが私に文法やスペルミスを指摘してもまったく気にしません。そのようにして、私は常に英語を上達させ続けることができます。そして、すべてのソースコードのすべての間違いを修正することは確かに難しくありません。単純なPerlスクリプトを簡単に記述して、フォルダー内のすべてのファイルをループすることができます。おそらくsedでもできますか？知りません。

だから、私は間違いなく他の誰かのコードの文法やスペルミスを指摘しますが、それは私が言っていることが正しいかどうかが絶対に確信している場合のみです。

ここで、HTTPプロトコルのHTTPリファラーヘッダーが「リファラー」としてスペルミスであったことに言及する価値があると思います（そして、私たちはそれと共に生きなければなりません/私たちはそれと共に生きることを学びました）。

私は、文法の誤りがあるコードは維持できないと言っている他の回答に同意します。

また、いくつかのことを追加します。

• コードは、英語を上手に話せない人や、英語が母国語ではない人によって書かれていることがよくあります。レビューするコードに文法上の誤りがある場合、これは同僚がこのエラーを行ったことを意味するものではありません。たぶんそれはウェブサイトからの単なるコピー＆ペーストだったのでしょう。
• 英語が同僚の母国語ではない場合、この間違いについて英語で話すのは良い考えかもしれませんし、非常に悪い考えかもしれません。フランスから来た私は、私が英語で犯す間違いについての発言をいつでも歓迎します。一方で、文法の間違いについて話すと本当に怪我をする人がいることを知っています。
• ジョン・R・ストロームが言ったように、決して公にしないでください。ほとんどの人はこれに本当に悩まされます。

スペルチェッカーが組み込まれたIDEを使用することをお勧めします。IntelliJ IdeaはJavaプログラムに対して素晴らしい仕事をします。関数の名前だけでなく、たとえば、ユーザーに表示される例外メッセージにも、キャッチする厄介なタイプミスが多くあります。タイプミスでいっぱいのメッセージを生成するプログラムは、それほど自信を刺激しません。

私がするのは

• プログラムの使用に影響します
• プログラムの精度に影響します
• 著者が修正されることを希望していることを明確に知っています。

補足として、関数名が文法を持つのに十分な長さである場合、おそらく長すぎます。与えられた例では、関数userHasPermissionを呼び出して、次のように「文法」をコードに移動します。

if userHasPermission() ...

これは私のプロジェクトでもたくさん起こります（ヘブライ語、ロシア語、アラビア語を母国語とする人々が住んでいます）が、より高いレベルでも-しばしば辞書が翻訳として作成したものであるあいまいな用語を使用するコードを見ます著者が念頭に置いていたもの、そして彼らが意味することとは何の関係もない

個人的には、頻繁に発生し、プロジェクトに参加する前からコードを書いていた可能性のある多くのチームメンバーが、それを無視する傾向があります。

ただし、以前に記述されたコードまたはコメントと同じファイルでいくつかの作業をコミットし、それらにタイプミスがある場合は、あまり作業ではないという理由だけで修正します。

ゴールデンルールが適用されます

あなたが彼らにあなたにさせるだろうように、他の人にしてください。

私は他の人にこの種のものに背を向けてほしいので、他の人を助けます。優雅で協力的であることは、あなたに有利に働くことができます。

他の多くの優れたプログラミングプラクティスと同様に、プログラムのスペルに関するポリシーを実装する唯一の客観的で非政治的で効果的な方法は、コミット前プロセスの一部としてポリシーを自動化することです。目的のために独自のツールを作成しなければならない場合でも、自動化は膨大な苦情からあなたを救います。

これはコードの小さな間違いですが、間違いです。見つけた他の間違いと同様に扱います。私のポリシーは、同僚が有能であると仮定し、そうでないことが証明されるまでそのように扱うことです。

それがたった一つの間違いなら、私はそれを直してチェックインするかもしれません。それがパターンなら、私はその同僚にそれらの修正を見直すようにさせるかもしれません。あなたは彼らが良いコーダーだと思うが、これは改善するのが良いだろうことを彼らに知らせてください。しかし、このようなことについて大したことはないと思います。

あなたがそれを大きな問題のように扱わない限り、その同僚を、エゴを台無しにすることなく改善できる立場に簡単に置くべきです。

userPermission（）おそらく？-

最後に出会ったのは、クラス名のスペルがハイライトであるため検索結果が強調表示されないというグローバルな問題です。見つけにくいバグ。

確かにそれを指摘しますが、スペルミスをチェックする時間を無駄にしないでください。ツールを使用して、CIでこれを自動化します。.netでは、fxCopでこれを実行できます...

それは主に、間違いが何であるか、どれほど一般的でどれだけ悪いか、そしてそれが実際に真正な間違いであるか、それとも言い方ではないかによって異なります。

馬鹿者が5分間のコードレビューを30分にドラッグするとき、私は個人的に我慢できません。 「データオブジェクトの読み込み」を「データオブジェクトローダーコンポーネントが関連するデータオブジェクトをデータオブジェクトストレージコンポーネントから読み込むように」変更する必要はありません。

/ rant :)