気分を害することなくどのようにコーディングしますか？

つまり、何年も取り組んでいて、それに精通している開発者と共有するコードベースでどのように開発しますか？

私は誰かの足の指を踏みつけたくありませんが、コードのホワイトスペースの方法やSVNへのチェックインの頻度（あまりにも頻繁に）について、私は物事のやり方についてそれほど微妙な不満はありません。そのため、これらのことは簡単に変更できますが、一般的にはより良いチーム開発者になりたいです。

質問する以外に何をすべきかはわかりませんが、おそらく皆さんは私が実践できる考えを持っているかもしれません。

更新

話すべきスタイルガイドはありません。コードベースの共有に慣れていないだけです。誰もが独自の小さなサイロ化されたコード世界を持っています。

これはperlショップですが、これらはどの言語にも当てはまると思います

更新2

後にCEOになったCTOは完全な誇大妄想であり、これらの不満の主な原因でした。Macを使用しているか、Emacsを使用しているか、2つではなく4つのタブスペースを使用しているか、特定の方法で服を着ているかどうか、彼が好きなことを正確に行わなかった場合、あなたは劣っていました。それは私が修正しようとした恐ろしい状況でしたが、私にとって唯一の正しい答えは去ることでした。

これは職場でのいじめの一例であると確信しており、その後、職場環境での微妙ないじめや不適切な行動が何であるかをよりよく認識しています。

このような状況への回答を探している開発者には、すぐに離れてください。悪いチーム状況から抜け出すためにチームワークすることはできません。

聞いて つまり、一緒に働く人に聞いてください。既存のコードの確立されたスタイルに固執するために最善を尽くします。特にコーディング標準のドキュメントリストがあるかどうかを確認し、それに従ってください。存在しない場合は、コードで観察した内容に基づいて最初のドラフトを作成し、他のチームメンバーに批評を依頼します。受け入れられたコーディング慣行の文書化を開始することにより、会社（およびあなたの後に来る新しい開発者）にサービスを提供します。唯一のリスクは、ベテランの人々が何が受け入れられるか、または受け入れられないかについて互いに同意しないことが判明した場合、おそらく途中で捕まることです。

また、自分自身であることを恐れないでください。あなたは新しい人かもしれませんが、あなたはチームのメンバーであり、あなたの意見は有効です。あなたが何かをするためのより良い方法を考えることができるなら、それを提案してください。他のチームメンバーと確立された方法を尊重しますが、他のメンバーに押し付けられないようにします。会社は、あなたのインプットを評価していなければ、あなたを雇っていなかっただろう。

チーム内で友好的で、特に質問に答えてくれる人を見つけることができれば、大いに役立ちます。（それが良いチームであるならば、それは皆であるべきですが、チームはいつもそのようではありません。）あなたの上司があなたを始めるのを助けるために誰かを割り当てたかもしれません。その人をリソースとして使用します。発生した質問を書き留めてから、その親切な人に時々質問に答えるよう依頼してください。

「あまりにも頻繁に」コードをチェックインする場合、定期的なコミット用に独自のブランチを作成し、コードの準備ができたらトランクにマージしてみませんか？それを行うことで他の人に害はありません。あなたの同僚があなたが望むSVNから利益を得ているのを見ると、彼らはあなたのリードに従うかもしれません。

空白に関して：ただそれを行うが、コードはすでにそれをしている。フローを使用してください。

SVNチェックインについて：それらを非常に明確に文書化します。それは人々がコードで何が起こっているのかを理解するのに役立ちます。（フォローアップ：頻繁なチェックインに対する彼らの反対は何ですか？）

一般的に：コーディング標準文書の作成を開始します。100個のルールで埋めようとしないでください。ルールが追加されたら、追加するだけです。

また、仲間の開発者に質問してください。それは、あなたが彼らが好まない何かをする前に彼らに計量する機会を与えます。さらに、関係を構築します。さらに、ショップの仕組みについて詳しく学びます。

コードの書式設定スタイル（空白、タブ、中かっこなど）に関しては、コードの一般的な標準に従う必要があります。ない場合は、文句を言う必要はないと思います。結局のところ、ブレースを独自の行に置くかどうか、メソッドパラメータリストの周りにスペースを置くかどうかなどは個人的な好みであり、長期的には実際にはそうではないため、一般的なスタイルに譲るべきです問題。重要なのは一貫性があることです。

SVNにコードをチェックインすることになると、私は自分自身を気まぐれにさせるのではなく、物事を行う正しい方法であると感じていることを伝道しようとします。テストをビルドしてパスしない限り、コードをチェックインしません。関係のない変更をいくつか行う場合は、作業をいくつかのコミットに分割します。何かがしばらく壊れる場合は、ブランチを作成してそこで作業を行います。コミットは説明的なコメントを取得します。これは、「金曜日の5:00に変更の山をチェックインする」方法よりも私の経験ではうまく機能し、ここや他の場所で読んだことのほとんどによると、それは一般的な「ベストプラクティス」のようです。

最初に彼らのコーディング規約文書を読んでください（もし彼らがいない場合は、あなたがそれを追うことができるようにそれらを書くように頼んでください）

次に、注意を払い、それと彼らの言うことを守るために意識的な努力をします。厳しいと思われるかもしれませんが、コーディング標準は重要です。後で大きな変更を加えたときに問題に発展するのではなく、今は何が間違っているかを指摘する方がよいでしょう。

初心者があなたのつま先を踏んでいるとき、あなたは1年か2年後に同じことをしていると確信しています:)

会社コードの標準を求めます。詳細に注意を払ってください。他の人が非常に特殊な形式の空白とブレースパターンに従う場合は、それらに従ってください。Sr.としては、これは目立たないと主張することもできますが、Jr。またはプロジェクトの新しい人として、リードする前にフォローできることを示す必要があります。

また、プロジェクトの新規開発者は、実際に必要な「ランプアップ」時間があることを理解してください。心配しないでください。

あなたができる最善のことは、彼らがあなたに与えるアドバイスに従うことです。彼らが望むものを前もって伝える方法はありません。あなたが超能力者でない限り。

ただし、人々からアドバイスがあったら、それを文書化することをお勧めします。ウィキはありますか？もしそうなら、それを使用します。そうでない場合は、ソースコードでチェックインされたテキストファイルをお勧めします。適切に編成されたプログラミングガイドを作成します。それはあなたが物事を行う方法を思い出すのに役立ち、誰かがあなたが与えられた以前のアドバイスに矛盾する場合、それはあなたに矛盾を議論するための参照ポイントを提供します。さらに、次の人がチームに参加するとき、彼らはあなたが経験していることを経験する必要はありません。

ドキュメント内のアドバイスを個人に帰属させないことをお勧めします（「コードブロックは3つのスペースでインデントする必要があるとビルは言っています」ではなく、「コードブロックは3つのスペースでインデントする必要があります」）。ただし、その情報を控えめな方法で記録できる場合（コミットコメントなどで「ビルのアドバイスに基づいたインデントに関する追加ルール」を書く）、矛盾を解決するのに役立つことがあります。何かに。ここで私が考えているのは、矛盾したアドバイスを与えられた場合、何かに同意しない2人の同僚に蹴られることを避ける必要があるということです。ちょっとしたカバーのアプローチですが、賢明かもしれません。

簡単な方法は、スタイルガイドを見つけてそれに従うことです。ほとんどの場合、攻撃的な要素は含まれておらず、他のユーザーを攻撃することはできません。