一貫したコーディングスタイルを持っていない同僚に対処しますか？

スタイルが悪いコードを書く傾向がある人と仕事をしているとき、あなたは何をしますか？私が話しているコードは通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントかもしれませんが、見た目はいだけです。私たちは持っている：

• 異なる命名規則とタイトルの混合（underscore_styleおよびcamelCaseおよびUpperCamelおよびCAPSすべては、同じ関数内の異なる変数に多かれ少なかれランダムに適用されます）
• 奇妙で一貫性のない間隔、例えば Functioncall (arg1 ,arg2,arg3 );
• コメントおよび変数名に多くのスペルミスのある単語

私が働いているコードレビューシステムは優れているので、最悪のものを調べて修正することができます。ただし、50行の「ここにスペースを追加します。「イタレーター」を正しく入力してください。この大文字化を変更します。」などの50行で構成されるコードレビューを送信するのは本当にささいなことです。

この種の詳細にもっと注意を払い、一貫性を保つよう、この人にどのように勧めますか？

コーディング規約に同意する

これが1ページャーであっても。チーム全員が座り、チーム全員が使用できる基本的な作業コーディング規約に全員が同意することをお勧めします。

私はあなたがしていることをやり続ける必要があると思います。コーディングガイドラインの明確なセットを用意し、コードレビュー中にそれらを実施します。開発者が何かをチェックインしようとするたびに「ここにスペースを追加」および「「イテレータ」を正しくスペル」の50または100行を取得し、それらすべてが修正されるまで実際にチェックインが許可されない場合、最終的に面倒を避けるために、よりクリーンなコードの作成を開始する必要があります。

NimChimpskyが提案したように、これらのことを自分で修正すると、この人を永遠に片付けることになると思います。

変数名のスペルミスやフォーマットは問題ではないと言った人全員にBSを呼び出します。明らかに、彼らは自分のコードを読んだだけです。そして、その言葉に気づいてください-読んでください。多くのスペルミス、ミッシュマッシュのフォーマット、一貫性のない行間、その他多くのソースコードに見られるさまざまな怠withを伴う本を読むことを想像してください。面倒です。

構文が機能するために100％正確でなければならない専門家にとって、実際の開発者がクリーンで一貫したコードスタイルを持たないという言い訳はありません。それ以外のものは、ずさんな怠け者です。私はいつも実装でだらしない形式のコードの正確性に疑問を呈しています。

私が働いているコードレビューシステムは優れているので、最悪のものを調べて修正することができます。ただし、50行の「ここにスペースを追加します。「イタレーター」を正しく入力してください。この大文字化を変更します。」などの50行で構成されるコードレビューを送信するのは本当にささいなことです。

自分で変更してから、コードに丁寧なコメントを追加します。

これは、質問が述べているようにスタイルガイドがすでにあると仮定しています：

優れたコードレビューシステムがあります

ですから、私の提案は最後の手段です。電子メールなどを送信するのと同じように、自分で変更してコメントを残すのも同じくらい迅速だと思います。

クラスや変数の命名などの慣習が重要であり、エレガントで効率的なコードも遵守する必要があると思いますが、私の答えが何度も落とされるリスクがあるため、一般的に「きれいなコード」パラダイムと言わなければなりません私見では非常に過大評価されています。

最初に、それを書いた開発者はそもそもそれを維持する必要があります。もし彼がバスにぶつかって、コードが「きれい」ではないので他のプログラマーがそれがどのように動作するか理解できないなら、私は言うでしょうとにかく、他の開発者はあまり良くありません。また、自動化されたフォーマッタ/ビューティファイヤが多数あるため、必要に応じてコードを美化するために誰でも使用できます。「フロー中」/「ゾーン内」で時間を無駄にすることはありません。

ここではスパゲッティ/カウボーイスタイルのコーディングを推奨しているわけではないことに注意してください。実際、非常にきれいにフォーマットされたスパゲッティコード（4〜5画面にわたる関数本体、さまざまなソースコードファイルに散在するグローバル変数、一般的に名前の悪い選択を見たことがあります）など）。

私の同僚の1人が、私の肌をうような方法でhtmlを書いています。私のhtmlが2つのスペースインデントで構成され、私の行末に追加されたタグによって断片にハッキングされ、立っているために腕を投げる必要がある酔っぱらいのように同じ行または次の行で終了することを想像してください。新しい行はめったにインデントされませんが、もしそうなら、その数字が何らかの方法でそのようなインデントで使用されるスペースまたはタブの数を反映するように、無理な温度値を吐き出す銀河の一部に非常に混oticとしたブラックホールがあると確信していますこの女性によって。運が良ければ、「</input>」で閉じられた入力タグが表示されます。あなたが理解できる完全な悪夢。

誰もこれを理解していないようです。ここで最も高いレベルで、組織化されたコードまたは組織化されていないコードをどのように見るかは、サンドイッチにスイスチーズまたはアメリカンチーズを置くことの違いのようです。つまり、彼らは本当にあまり気にしません。私は別のプロジェクトでストレスを感じていたので、それをスライドさせ始めました。そして、彼女は彼女が改善したい前にそのようなコードを理解することがいかに難しいかを認識し始めたと思います。私のアドバイスは、単にコードにスタイルを設定するほうが、コードにスタイルを設定する方が好ましい理由を示すことです。

私が話しているコードは通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントです...

あなたがすべてを手に入れたことを嬉しく思います。ほとんどのプログラマーは、おそらくあなたにそのリストの最初のものを与えるでしょう。変数の命名と間隔は、最も重要なことだと思います。

スタイル規約を設定して同意する必要があるように思えます。そうしないと、3つのスペースインデントがあるライブラリ、4つのスペースインデントを持つライブラリ、Camel Caseを使用するライブラリ、underscore_caseを使用するライブラリがあります。

あなたがあなたの個人的な好みを作りたい変更はありますか、またはあなたが従うべき実際の基準を持っていますか？実際の標準がない場合は、これを行わないでください。最初に標準を設定します。その後、コードを標準の設定にリファクタリングするように設定できるソフトウェアを入手できます（少なくともいくつかのことは）。

標準がある場合は、コードレビューで強制を開始します。コードレビューで標準を強制しない場合、標準を使用しても意味がありません。これは、人々が標準に触れたときに元々標準に適合しなかった古いコードを修正する必要があるため、メンテナンスに多くの余分な作業が必要になることを意味します。

標準がなくても、変数名のつづりの間違いを修正することを主張します（コメントについては特に心配しません）。

コーディング標準を特定して、誰もが自分が何であるかを認識し、それを実施する必要があるようにする必要があります。ルールに従わない場合、結果が生じるはずです。

インセンティブを提供するものは次のとおりです。

1. コードレビューは退屈で、必要以上に長くなります。
2. コードはより頻繁に拒否されます。
3. スケジュールは満たされません。

誰もあなたのルールを強制しないため、または彼らが非生産的であるかどうかを気にしないので（そして誰もそれについて何もしません）、この人がこれについて心配する必要がない場合、あなたはそれについて多くのことができません。

私はプライベートチャットをすることを提案し、あなたの両方が根本的な原因を見つけることができるかどうかを確認したいと思います：

1. 同僚は急いでいますか、誰かが昨日コードを望んでいたので、その人はできるだけ早く何かを動かそうとしていますか？これは、この人に仕事のスピードよりも品質に集中するように伝える機会になる可能性があります。「時間をかけて」などのマントラは、これが逆効果でない場合に役立ちます。

2. 人は自分の作品をどのように見ますか？自尊心がある場合、改善するために使用する角度があります。それが請求書を支払うだけの仕事である場合、変更を取得するのははるかに難しいかもしれません。彼らは素晴らしい仕事をしていないが、それにとても近いことを知っていますか？

3. この人は規約に同意せず、抗議してコーディングしようとしていますか？もしそうなら、あなたは大きな問題を抱えているかもしれませんが、これが事実なのか、それとも単に怠け者なのかを知る価値はありますか？ここでどのような動機付けが役立つか、例えば、欲望、プライド、または他の悪徳に訴えて、人を改善させてください。これは卑劣ですが、ナイスガイのルートを試みてもどこにも行かない場合に効果的です。

4. 友だちと影響力を獲得する方法人々は、改善を賞賛したり、その人に立派な評判を与えるなど、うまくいくかもしれないという説得力のある観点からいくつかの提案をしています。

これを非公開にする必要がある理由として、いくつかの理由があります。

1. 屈辱、批判、その他の不快感は、誰かが自分のキャラクターが暗殺されていると感じる可能性のある野外で放置されるよりも、ドアの後ろに保管するほうが良い可能性があります。

2. あなたは、この他の人に少し開かせることを奨励したいのです。ここでの課題は、一部の人々が非常に警戒されており、壁を取り壊すのに時間がかかることがあるということです。

3. 可能であれば、オフィスから少し離れてこれを行うことをお勧めします。昼食に出かけたり、散歩をしたり、周囲の環境が十分に変化して、その人がもう少し快適に感じるように何かをします。これは困難な場合があり、人を知る必要がありますが、ここでの考え方は、オフィスでは、ここでは役に立たない可能性が高い作業マスクを着用する人もいるということです。

4. 会話がかなり白熱したりいものになったりする準備をしておきますが、他の人を引き付けて良い会話をすることができれば、これは良い兆候かもしれません。物事をオープンにしたい人もいれば、もっと微妙な方法で物事を成し遂げたい人もいます。重要なのは、相手の話を聞き、相手の側のことを理解し、理解しようとすることです。

フォーマットの問題を探すJUnitテストがあります。ビルドの一部として実行されます。if、while、forと開き括弧の間のスペースを省略することにより、継続的にビットを取得します。ただし、コードは一貫してフォーマットされています。

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

unscrutifyのようなコード美化は、あなたの問題のいくつかを解決することができます。これにお金を払う準備ができている場合、Parasoftのようなソースコード自体にルールを埋め込む高レベルのソフトウェアがあります。Parasoftでは、統一されたスタイルでコードを記述することが義務付けられています。独自のルールを埋め込むこともできます。そのようなツールが使用されると、開発者は統一されたスタイルを使用することを余儀なくされます。そしてしばらくすると、彼らはそれに慣れるでしょう。

Eclipseを使用する場合は、Javaエディターのアクションの保存を有効にして、全員に使用するように伝えます。これにより、保存するたびにフォーマットの問題が修正されますが、大文字小文字の間違いは修正されません。しかし、それは非常に役立つかもしれません！

スタイルの規則に従うのはどれくらい難しいですか？私はスペルミスを理解していますが、残りはずさんな思考とコーディングの指標です。本番コードに関しては、一貫性を保つ必要があることを人に伝えてください。なぜなら、彼らはそれを見ているだけではないからです。一貫性のないスタイルで製品コードを書くことは、単なる無礼で、利己的で、思いやりのないことです。

笑。あなたは私のコードを絶対に嫌います。私は自分の命を救うために綴ることができず、気にしません。

しかし、実際にそれらのことを気にしている人がいることは知っています。

そのいコードを変更しない場合は、そのpersonいコードを書いている人を解雇し、物事を本当にきれいにしてくれる人を見つけて、

通常は技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントです

そして、もしそれができなければ、少なくともあなたは壊れたきれいなコードを顧客に見せて、それを売ることができます！

しかし、真剣に。最初に実際に重要なことに集中してください。「私の繊細な感性を傷つける」以外に、しっかりした確かな理由が見つからない場合は、今のところ無視してください。それが実際に重要な場合は、その人と一緒に座って、その重要性を説得します。クラスレベル、メソッドレベル、共有、定数変数の違いを簡単に判断できる標準などが違いを生みます。問題のコーダーが自分の職業にまったく関心がある場合、コーダーは理解して正しいことをしようとします。

書式設定について＆％$＃を提供しない（またはその問題を簡単に防ぐことができる）アウトソースリソースを扱うときの私のソリューションは、ビルドサーバーにこれを強制することでした。毎晩実行するCIサーバージョブを作成し、コードをチェックアウトし、Jalopyを実行してfindbugsを実行し、コードをチェックインしました。標準形式を維持するIDE。