これらすべてのコーディング規則はどうですか？

私は、会社や特定のプロジェクトの開発者向けにコーディングルールを設けるという考えを常にサポートしていました。特に、会社の規模が10を超える場合は、会社が大きくなるほどニーズも大きくなります。私は多くの人が意見を異にするだろうことを知っていますが、それらを持たないプロジェクトを見たことがあり、コードは完全な災害のように見えます。

これから来る本当の問題は、ifステートメントで角かっこを使用したくない、またはコード内のどこでも同じ接続文字列を使用したくない、またはそれらを反対にせずにコーディングルールを使用したくない頭のいいものを作成する方法ですアイデア？

ルールの戦いよりもむしろ問題の修正に参加してもらいます。私は個人的には、「スタイルガイド」、「コーディング標準」、またはそれに類似したものを好むので、これにより、「ルール=悪い」反応を防ぐことができます。

しかし、たとえそうであっても、私はルールが理由のために配置されていると思う傾向があり、頭の固い人々が好転するようにする方法は、ガイドラインに従うことによって彼らがコードをより簡単にするのを助けていることを彼らに理解させることですみんなのために読んでください。

時々、仲間からの圧力がこれに対する最善の解決策です。

私の仕事では、次の3つのソリューションすべてを使用します。

1）優れたCheckstyle（Javaの場合）やStyleCop（C＃の場合）などのコードスタイルチェッカーを採用します。これらは簡単に設定できるツールで、コーディングスタイル/ルールの逸脱を自動的に強調表示できます。それは誰もが受け入れられるものと受け入れられないものを決定する中立的なサードパーティを提供します。

2）保存時にコードを自動的にフォーマットする自動保存再フォーマットコードテンプレート（Eclipseを使用した例はこちら） （およびVisual Studio用の別のテンプレート）を採用します。これは、誰かが好きなようにコーディングできるようにするのに最適ですが、すべてのコードは保存/コミット時に同じ方法でフォーマットされます。私はこれが本当に好きで、コードの一貫性はかつてありませんでした。

3）コードレビュー。うまくいけば、とにかくこれらをやっていますが、これらが強調すべき1つのことは、コーディングルール/スタイルが慣習に違反しているところです。

上記に加えて、全員が同じボートに乗っており、彼らが目指しているスタイル/ルールに同意していることが重要です。すべてについて全員から同意を得られるわけではないことを明確にしますが、チームの決定に忠実であるようにチームからのコミットメントを求めます。それらを使用した実際の経験とチームの離職を説明するために選択されたスタイル/ルールを時々見直すことを忘れないでください。

これから来る本当の問題は、ifステートメントで角かっこを使用したくない、またはコード内のどこにでも同じ接続文字列を使用したくないなど、難しいものをどのように作成するかです。

ブラケットを使用しないことで「ハードヘッド」されているのですか、それとも「ハードヘッド」リクエストですか？

あなたの戦いを選んでください。これは選ぶ価値のあるものの1つではないかと思います。「コードの最初のチェック」に関するこのレベルの詳細に近いと予想される場所で作業するのは楽しいと思いません。これは、チームがリファクタリングを理解していないことを示す赤信号です。

OO 101：「製品​​が必要なことを実行するときにリファクタリングする」。前じゃない。

それは彼らがかっこつけ確認して、大規模なチームで一つ一つの開発者の肩の上に座ることはかなり困難だあなたは、彼らが行くべきだと思う-その1の信頼を私に;）。

それがあなたの開発を本当に妨げていると感じるものであるなら、あなたは「門番」を必要とするでしょう。たとえば、コードレビューなしで人々にチェックインさせないでください。テクニカルアーキテクトまたはチームリーダーにコードをレビューしてもらい、コードスタイルを「修正」するまで拒否してもらいます。彼らはすぐにこれに飽き飽きし、ルールに適応しますが、おそらくチェックされている間だけです。

もちろん、一部の企業では、ジュニアプログラマーからチェックイン特権を完全に奪っています。彼らが最終的に会社のコーディング規則を学ぶとき、彼らは特権を得ます。

私はあなたが非常に異なるレベルの問題について話していると思います：

ifステートメントで角かっこを使用したくないハードヘッドの作成方法、

明示的な演算子の優先順位の問題がない限り、これは主にスタイル/可読性の問題です。後者はあまり一般的ではないはずで、とにかく単体テストが可能なため、修正が簡単です。前者は、得るものはほとんどないが、チームの士気に深刻な悪影響を与えることなく、簡単に聖戦に戻ることができます。ですので、注意してください- 少なくともいくつかのチーム/コミュニティによって受け入れられ、機能することが証明されている、試行およびテスト済みのルールのみをプッシュしてください。

または、コードのどこでも同じ接続文字列を使用します。

マジックコンスタントを意味する場合、それは確かにメンテナンス（および潜在的にセキュリティ）の問題であり、そのため私見では、経験豊富な開発者はそれが悪いことであることを理解し、受け入れます。

または、アイデアに反対せずにコーディングルールを使用するには、

コーディングルールに同意するように人々を強制することはできません-唯一のチャンスは、共通の理解を得て、ディスカッションや（激しい）討論を通じてチームメンバーから賛同を得ることです。論理的で説得力のある引数を使用し、各ルールの背後にある値を示し、内在する習慣を調整することの不便さをどのように支払うかを説明する必要があります。一方、承認されたルールに従って、チェックイン時に自動コードフォーマットを導入するなど、移行をできる限り簡単にするよう努めます。

それでも、人々が異なる意見を持っていることを受け入れる必要があるだけなので、誰もが受け入れることができるコーディング規則は、特定の点で寛容になります。それを受け入れ、より少ない努力で物事を改善できる領域に焦点を合わせます。

ルールの確立に参加してもらいます。これは通常、フォローするように人々を促すのに役立ちます。

これがコードレビューの目的です。コードレビューアは、基準を満たさないコードを通過させないでください。緊急修正のルールを緩和しないようにしてください。プレッシャーがかかった状態で数回やり直す必要がある場合は、最初から適切に仕事をしたがらない人を修正します。

どこでも同じ接続文字列？これに対する解決策は、すべての重複を取り除くまでリファクタリングすることです。コピーと貼り付けのプログラマーはプログラマーの刑務所に行くべきです。（笑わないでください！Steve Ballmerが監視員です。）

しかし、ここでの実際の問題は、「make」という動詞です。プログラマーに何かをさせることはできません。そうすることで、プログラマーの最も重要な特性、つまり、気になる何かに取り組むことから生じる深い知的関与を無駄にすることになります。

私がそれを解決する方法：

1. チームに共通のコーディング標準があることを主張します。長さは5行ですが、すべて同意する必要があります。
2. 議論に気づくたびに、彼らはそれをまとめてコーディング標準に入れると主張します。人々が物事を前後に再フォーマットしていることに気付いたら、それを議論として扱います。
3. 標準の項目が合意されたら、コードベース全体を一度にクリーンアップするツールがあるかどうかを確認します。
4. 数か月ごとに、コーディング標準を確認し、どれがまだ真実で関連性があるかを確認します。この規格は、人々が何をしているかを文書化しているだけです。そして、明らかになった項目を標準に保つ意味はありません。

プログラミングはチームスポーツ、または集合的な芸術作品です。人々が同意することは、彼らが同意することほど重要ではなく、必要に応じて新しい契約を結ぶのが得意です。