同僚が外観を変更するためだけにコードを編集している場合はどうしますか？

同僚がコードを編集している場合、何をすべきですか？

機能を追加したり、バグを修正したりせずに、外観を変更するだけです...

それについて彼らに話してください。「彼らは私をいらいらさせるためにこれを行っているのではなく、彼らが何らかの形で強迫性障害を持っているからだ。彼らは私のコードを改善しようとしている」という態度で会話に入る。

あなたが間違っている可能性があるため。それは微妙なバグ修正である可能性があり、あなたはそれを見つけませんでした。

または、違反していることを知らないコーディング標準があり、それを修正しているだけかもしれません。

または、彼らがあなたを困らせようとしている、または何らかの形の強迫性障害を持っている可能性があります。それが事実である場合、停止するように彼らにきちんと頼み、それがはたらかない場合、あなたの上司とそれを取りなさい。

しかし、あなたが尋ねない限り、あなたは決して知りません。

私のコードが私を悩ませるためにそれを探す方法とはあまり結婚していません。:)私は変化から学ぼうとします。同僚は変数名を調整しましたか？より効率的なループを作成しますか？コードを読みやすくしますか？

変更によって既存のものがどのように改善されたかがわからない場合は、通常、変更を行った同僚に、その背後にある動機を尋ねます。その利点は私には明らかではない可能性があります。そして、私が正しく、彼らが間違っているなら、おそらく私が書いたように書いた理由を説明できるでしょう。

他のすべてが失敗した場合、チェックインを元に戻します。;）

編集：しかし、見た目を変更したいという要望がバグを引き起こした場合、すべての賭けはオフになります。

とにかくあなたとあなたのチームはコーディング標準を使用する必要があります。この場合、質問は「元のコードは標準に準拠しましたか？」になります。「はい」の場合は、機能的に変更しない限り、同僚がコードに触れてはいけません。「いいえ」の場合、あなたの同僚があなたのコードを整理するすべての権利を持っていると思います。プロジェクトリーダーとして、私は常にそれをやっています。

コーディング標準を使用していない場合、「良いコード」を構成するものの議論全体があまりにも主観的になります。したがって、コーディング標準を使用する必要がある理由:)

一つとして、これらの人々 （時には他の人のコードを再フォーマット人）、私はそれを行う主な理由は、読みやすさです。一部の人々は、インデントまたはタブとスペースの混在に非常にずさんです。

私が変更する習慣がある主なことは、長い行を減らして、水平スクロールなしですべてを読むことができるようにすることです。複雑なステートメントを個別のステートメントに分割するか、メソッド呼び出し/宣言を再フォーマットして、すべてが1行に収まらない場合は、1行に1つのパラメーターをリストします。また、英語のエラーを修正するため、または単にわかりやすくするために、コメントを編集します。

はい、そのままにしておくこともできますが、コードを読むために必要な精神的な労力を減らしたいと思います。

あなたはそれについて何をすべきですか？まず、おそらくこの人があなたのコードを改善していると考えてください。また、コードをどのようにフォーマットするかについて、チーム内でコンセンサスを得る必要があります。各人が異なる習慣を持っている場合、それは皆を遅くします。彼らがあなたのコードをより良くしておらず、それらが穀物に反しているなら、あなたはそれについて彼らに立ち向かう必要があります。それがうまくいかない場合は、他の人を巻き込む必要があるかもしれません。

彼らがそれをしている理由を彼らに尋ねてください。有効な説明はあなたの欲求不満を和らげるかもしれませんが、どれだけあなたを悩ますかを彼らに知らせるべきです。誰が知っているか、多分彼らは彼らがあなたに好意を与えていると思っていて、それがあなたを怒らせると彼らが学ぶとき停止するでしょう。または、病状に本当に苦しんでいる人に対処している場合があります。

許可されていますか？変更によりコードが改善されますか？もしそうなら、あなたのプライドを飲み込みます。コードの品質が悪化していると感じた場合は、同僚と協力して、明らかな利益なしにコードを変更する必要があると感じた理由を同僚に尋ねます。それが悪意で行われている場合、または人があなたよりも自分が優れていると誤って感じており、あなたと一緒に解決できない場合は、上司に取り上げてください。

IDEのようなVisual StudioにはFormat Document、ユーザーがIDEで設定したルールに従ってコードをフォーマットするというオプションがあります。同僚がこれを使用している可能性があります（知らないうちに自動的に、または意図的なアプリケーションによって）。おそらく彼らのIDEはタブの代わりにスペースを使用します、またはその逆で、これらは知らなくても自動的に適用されますか？しかし、あなたは彼らと話す必要があります。

ちなみに、明らかに何らかの形式のスキームに従っていない（つまり、あちこちにある）場合は、同僚のコードを再フォーマットすることがよくあります。それは彼らに気づかせる微妙な方法です。（ただし、きちんとした場合は再フォーマットしませんが、好みではフォーマットしません）。

チームのコーディング標準を満たすように彼がそれを変更している場合、次回は標準に従う必要があります。

チームのコーディング標準に従わないように変更した場合、彼が何を間違っているのかを伝え、元に戻してもらいます。

...あなたのチームには、誰もが使用する一連のコードフォーマット標準がありますか？

乱雑な同僚が書いたコードをときどき並べ替えます（またはコメントのタイプミスを修正します）。彼らは、私がコードのフォーマットと順序に執着していることを知っているので、文句を言わずにそれをさせてくれます。時々、無料のソーダやクッキーもくれます。

もちろん、SVNの「非難」機能を壊したため、これは時折の作業です。

これは、ある種のコードレビューを行うための非常に基本的な方法でもあります（通常、作業中のモジュールで同僚がコミットしたコードのほとんどを読みます）。

コード規則がある答え。仕事で持っている必要があります。そうでない場合は、今すぐ開始してください（良い出発点はgoogleスタイルガイド）。書かれた（または少なくとも一般的に知られている）ルールがある場合、あなたの質問への答えは簡単です。

そうするのは不快だと思っているのではないでしょうか...？たとえば、私自身がこのコードをすぐに修正します

int myFunction( ) {

    int i ;
  return  0;

}

になる

int myFunction() {
    int i;
    return 0;
}

だから...私は自分の行動のために罰せられるべきですか？実際には、「フォーマット」と書かれたSVNログがたくさんあります。;-)

スタイルチェックツールを使用する

使用を開始 StyleCopまたは同様の、コードスタイルルールを適用し、すべての開発者がそれを使用することを義務にします。すべてのコードは例外なく同じように見えます。そして、あなたの組織にとって最も適切なルールを議論するために、賢明な人々と一緒になってください。デフォルトのルールは、既に.netフレームワークのコード自体と非常によく似ていますが。

それが最も簡単な方法です。私は以前の雇用主の誰かが他の誰かのコードを修正しているのを発見しました。なぜなら、この他の男は、過剰な量の空行とインデント規則のないコードを書いていたからです。実際、コードは平均的な開発者には読めません。StyleCopが存在すれば、私たちの多くは本当に幸せになります。

これはリファクタリングについて話しているインターネットで私が見た考えであり、おそらく誰かがあなたのコードに手を加えて改善する理由を説明しています：

どうして？

リファクタリングする主な理由は2つあります。

1. その上に構築する前にコード/設計を改善するには：最初の試みで良いコードを思い付くのは本当に難しいです。初期設計を最初に実装しようとすると、ロジックを誤って解釈したか忘れたことがわかります。

2. 要件の変更に適応するため。ソフトウェア開発で変化が起こります。変化に敏感に反応することは、優れたコードベースを持っている方が良いです。両方のシナリオに対して、コードのパスまたはリファクタリングの2つのオプションがあります。コードにパッチを適用すると、メンテナンス不能なコードになり、技術的な負債が増えます。リファクタリングすることは常に良いことです。

いつ？

1. 早ければ早いほど簡単です。

2. コードがほぼ完成するのをリファクタリングするのを待つのではなく、最近リファクタリングされたコードをリファクタリングする方が速くてリスクが少ない。

何？

1. すべてのコードとデザインはすべてリファクタリングの候補です。

2. 何かをリファクタリングしない例外は、品質が低い作業コードである可能性がありますが、期限に近づいているため、計画を立てるリスクよりも技術的な負債を残すことを好みます。

両方にとって素晴らしいことであり、将来的にあなたの時間を節約するならば、あなたは彼に彼のベストを尽くす必要があります！

乾杯