チーム内で競合するJavaスタイル

私は6週間の期限があるJava開発チームの一員です。そのため、大量のコードを非常に迅速に作成する必要があります。ただし、開発チームにはさまざまなスタイルのコーディングがあります。名前の規則から抽象化の方法まで、すべてがチームによって異なります。Javaの「標準」を規定するドキュメントを知っている人はいますか？

明確にするために、たとえば変数や関数の適切な命名規則を規定する組織があるかどうか疑問に思っていました。このような短い期限では、お互いのコードを理解しようとする時間を費やすことができないため、これは最重要事項です。

そのような組織があります：Sun / Oracle自体。このドキュメントは、Javaプログラミング言語のコード規約と呼ばれ、必要な規約のほとんどを説明しています。誰もがそれを読んでその推奨事項に従うことに同意してください。

私は本当にAndresの答えに注目し、Javaコードを均一にフォーマットする側面に焦点を当てています。

Eclipseを使用している場合は、Javaフォーマッターを設定して、Java標準に自動的にフォーマットすることができます。Eclipseフォーマッターには、1行あたりの文字数（新しい行に分割されるまでの1行あたりの文字数など）など、その他の便利な設定もあります。行あたりの文字数を標準化することが容易にそれを作る差分だけ間隔と改行からの違いの多くを持つことなく、異なる開発者によって書かれたコード。

最後に、Eclipseを使用して、必要なすべての設定を行った後、チームのすべてのメンバーがインポートできるファイルとしてフォーマッターをエクスポートします。したがって、Eclipseを使用している場合は、自動フォーマットおよびコード編集を行うすべてのオプションを完全に検討し、チーム全体で設定を共有することを強くお勧めします。

他の主要なJava IDE（IntelliJおよびNetbeans）には、フォーマット設定をエクスポートするための同様の機能があると思います。

この[異なるコーディングスタイル]は非常に重要です。このような短い期限では、互いのコードを理解しようとする時間を費やすことができません。

実際に。最重要ではありません。

コンサルタントとしての30年後、私は多くの顧客から多くのコードを読みました。すべての顧客（および多くの場合、顧客の組織内）にはさまざまなスタイルがあることに注意することが重要です。

非常に多くのスタイルを読んだ後、私はこれを学びました。

スタイルは関係ありません

常に機能するコードの作成と、常に機能することを証明する単体テストの作成に焦点を当ててください。

動作するコードを出荷した後、修正するバグやインストールする機能強化がなくなった場合は、それをドレスアップできます。

完璧な普遍的な標準を選ぶことを心配しないでください。必要なのは、チームが1つの標準に同意してそれに従うことだけです。必要に応じて独自に構成しますが、一貫性を保ちます。

一貫性はコラボレーションを改善し、コラボレーションはコードを改善します。

実際の一貫性が役に立たない場合でも、チームが協力して合意に達したという事実は良いことです。コーディング規約のような単純なものに同意できないことは、表面に潜む大きなチームワークの問題があるかもしれないと言っています。

上記のSun Java CCは13年前のものであり、一部のルールは古くなっています（1行に80文字など）だけでなく、最も一般的なもの（クラスのキャメルケース、ブロック大文字）を除いて、命名規則を定義していません静的な最終変数など）。

使用するDAO、EJB、エンティティなど、さまざまなタイプのクラスに対して独自の標準を定義する必要があります。Sun Java CCは、拡張用の抽象基本クラスのようなものです:)

ここで他の人が述べたように、Javaの数少ない人気の「スタイルガイド」の1つをオンラインで検索し、チームの全員にそれらに固執するように説得できます。お気に入りのIDEの一部のコードチェックツールは、そうしていないときに思い出させるのに役立ちます。

しかし、時には政治が関係します。かつて、誰かが標準化の必要性に言及した後でも、チームの最も上級の開発者が自分のやり方でそれを続けている状況にいます。そのような状況では、おそらく彼はコードベースと要件について最も多くの知識を持っているので、彼のコードスタイルを観察し、彼に従うことをお勧めします。それは私たちの残りがその特定の状況でやったことであり、私はしぶしぶ従います。

そのため、あなたの状況も考慮することが重要です。

ボブおじさんは、彼の本「Clean Code」で、より現代的で最新のコーディングスタイルを示しています。残念ながら、アイテムのリストは含まれていません。あなたはそれを読む必要があります。彼は、自分の規約を見るには、自分のコードを読む必要があると自分に言います。ボブおじさんは間違いなく一種の機関です。この本はとにかく優れた読書なので、今すぐ読むのが遅すぎても、できるだけ早く読んでください。

コードで本当に重要なのは、低い循環的複雑度、小さなスコープ、高い凝集度、表現力豊かな識別子の選択です。それらを考えると、コードは理解しやすくなり、そのようなコードは優れています。

Spartanプログラミングを検討することをお勧めします。

ほとんどのコーディング標準は、不完全に記述されたコードをきれいに見せるための方法を示しており、「コーディングスタイル」に関するほとんどの議論は、実際にはフォーマットに関するものです。コードのフォーマットとは、コードの構造を視覚的に表現することです。コーディングスタイルはコード構造の表現方法ではなく、コードの構造方法であるため、簡単で自動化可能であり、コーディングスタイルで何もする必要はほとんどありません。
命名規則については宗教的な戦争もたくさんありますが、実際にはそれらは貧弱なデザインを回避するためのハックにすぎません。名前が意味することを言っていれば、名前は良いことです。スコープが小さく、明確であればあるほど、そのような名前を選択しやすくなります。