組織のコーディングスタイルはオプションですか？

このプログラミングスタイルのドキュメントには、次のような一般的なルールがあります。

強い個人的な異議がある場合、規則に違反する可能性があります。

これは私が考えている方法と衝突し、コーディングスタイルが実際に重要であると言っている多くの記事があります。たとえば、これは言う：

コーディング標準ドキュメントは、開発者にコードの記述方法を伝えます。各開発者が独自のスタイルでコーディングする代わりに、ドキュメントで概説されている標準に従ってすべてのコードを記述します。これにより、大規模なプロジェクトが一貫したスタイルでコーディングされるようになります。パーツが異なるプログラマーによって異なって記述されることはありません。このソリューションはコードを理解しやすくするだけでなく、コードを見た開発者がアプリケーション全体で何を期待するかを確実に知ることができます。

だから、私はこの文書とこの質問の冒頭の引用から何かを誤解していますか？コーディングスタイルを本当に無視できるのでしょうか？

たぶん、私は十分に明確ではなかったので、この編集では、少し明確にするつもりです。

私はチーム用にコーディングスタイルドキュメントを作成していますが、いくつかの静的アナライザーを使用してスタイルを確認したいと思います。失敗すると、Jenkinsはメールを送信します。そして、スタイルが一致しない場合、コードレビューに失敗します。これは明らかに最初の引用と衝突します。

しかし、引用が正しい場合、誰かが望むことを何でもできるなら、コーディングスタイルドキュメントの使用は何ですか？

私が知る限り、あなたを混乱させた声明は、ガイドラインをできるだけ多くの読者に提供するために作られた実用的な妥協です。特定のコンテキスト（詳細は以下）に応じて、それを調整し、ガイドラインをより効率的に使用するオプションがあります。

ガイドラインでは、違反を正当化する手段として「個人的な強い反対」を参照しています。このような異論は、特に経験豊富な開発者からのものである場合は、軽視すべきものではありません。

これらの異論は間違っているかもしれませんが、（これは非常に大きいですが）一般的にまたは特定のプロジェクトのコンテキストで特定のルールが間違っていることを示す場合もあります（ルールの不適合の一例は、提供する要件です）パフォーマンスが重要なコードの詳細なロギング）。

賢明なスタイルガイドは、上記を考慮に入れ、それ自体を調整する可能性のあるニーズに対応しようとするべきだと思います。今、あなたを混乱させたガイドが、効率的でスムーズなプロセスと環境を備えた成熟したチームのみを対象にしている場合、以下のように、あいまいさをはるかに少なく述べることができます。

チャレンジはルールに厳密に準拠する必要があります。チャレンジが発生した場合、チャレンジされたルールは解決されるまで無視されます-チャレンジを拒否するか、受け入れてルールを調整します。

上記の方が好きかもしれませんし、誰にとってもそのようにしたいかもしれませんが、「チャレンジが発生する/無視される/調整される」という部分を詳しく見て、どのように実装できるかを自問してください。プロジェクトとチームによってはどれくらいかかるかを自問してください。1時間かかる場合、それは受け入れられますか？1日、1週間、または1か月かかる場合はどうなりますか？

ご存知のように、その課題を解決し、解決するまで無視するアプローチは、プロジェクトのガイドとして提示された場合、悪用の大きな扉を開く可能性があります。「ええ、そうです。ガイドの説明に従ってください。まず、このチャレンジフォームに記入し、CEO / CFO / CTOの承認を取得します。これには1〜2週間かかります。その後、コードチェックが更新されるまで待ちます;これには1〜2週間かかる場合があります。一方、パフォーマンスが重要なコードが、レジスタの移動ごとに適切にフォーマットされたロギングステートメントを吐き出すようにしてください。」

私はガイドの著者の心を読むことはできませんが、上記のように混乱を正当化するためにそれを使用することを避けたかったと仮定することは合理的に見えます。この観点からは、ガイドが強制を想定していないことを明確に述べる方が安全です-この方法は、たとえ不器用であっても、任意の幅広いチームやプロジェクトで使用できるようにします。このような広い許容範囲により、開発者の生産性を損なうことなく合理的にそれを絞り込む機会が、より成熟した効率的なチームに残ることが期待されるでしょう。

特定のケースに適用し、チームのコーディングスタイルドキュメントを作成し、スタイルが一致しない場合はコードレビューに失敗する-開発者が特定のルールに挑戦し、無視するのにかかる時間を把握する必要があると思います。解決し、解像度に応じて変更または回復します。

開発ワークフローに多くの障害を持ち込まずにこのプロセスを機能させる方法を考えている場合、「大声で泣くと違反する」のではなく、正式で追跡しやすい課題/解決アプローチを検討する価値があります。

サイドノートとして、あなたが別のコメントで書いたものに対処したいと思います。「コーディングスタイルが理想的であると仮定し、そうでない場合など」

これは本当に危険な仮定です。私はそれで鼻を折った（2回！単一のプロジェクトで！私は広大な経験があり、私はそれについてすべてを知っていると想像しました）、それを落とすことを強くお勧めします。スタイルガイドに間違いがある可能性があると想定し、そのような間違いが見つかった場合の対処方法を検討する方が安全です。

個人的な好みのためにコーディングスタイルを人々が無視できるようにすることは悪い考えです。

あなたの質問の引用文は、開発者なら誰でも「私はこのスタイルが好きではないので、このスタイルを使うつもりはない」と言うことができるようです。

これは、チームの全員が一貫性と読みやすさのために同じ方法で物事を行えるようにすることです。

私はそのような声明を伴うスタイル文書はおそらく無意味であることに同意します。

それでも、スタイルガイドラインを順守するための柔軟性をお勧めします。

• ガイドラインに従っていると、特定のコードを書く最良の方法が妨げられる可能性があります。開発者は、ガイドラインを無視して、自分がやったことが、この場合に何かを達成するための最良で最も読みやすい方法であると主張することができるはずです。
• レガシーコードを使用するには、柔軟性が必要な場合があります。 おそらく、既存の大規模なコードベースのスタイルを変更するのに、時間を有効に活用できないでしょう。特定のセクションを大幅に書き換える場合、好みのスタイルに再フォーマットできます。ただし、少し変更を加えるだけの場合は、コードの既存のスタイルを使用することをお勧めします。
• スタイルガイドのあらゆる小さな違反についてニッティングすることは、時間の有効な使用ではありません。 コードレビューは、チームのスタイルと大幅に一致しないコードを強調する良い機会です。しかし、小さなスタイルの「間違い」を見つけて修正することは、間違ったことに焦点を当てた忙しい仕事になる可能性があります。もちろん、スタイルが露骨に無視された場合、コードレビューに失敗します。しかし、アナライザーを実行して、すべての誤った括弧またはインデントを指摘するという考えは好きではありません。

結論として、チームのニーズに最適に対応するために、スタイルガイドラインを順守する柔軟性を許可しますが、個人的な好みなどのarbitrary意的な理由のためではありません。

コードを読みやすくするためのコーディングスタイルとスタイルガイドがあります。また、複雑さを軽減するために読みやすさがあります。

したがって、最終的には、組織のニーズに合わせてコーディングスタイルに違反する（適応させる）かどうかは、物事をわかりやすくするのにどれだけ役立つかによって決まります。

OOプログラミングから関数型パラダイム、さまざまな同時実行モデルまで、すべてが存在することを忘れないでください。それは、人々が複雑さに対処するのを助けるという唯一の理由のためです。

誰でも、コンピューターが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを作成します。-マーティン・ファウラー、2008

組織のコーディングスタイルはオプションですか？

組織はコーディングスタイルを選択します-そもそもコーディングスタイルを使用する必要はありません。

したがって、あなたが読んでいる引用文は、「スタイル」と本物のスーパースター「ハッカー」のコーディングに関して私が見る最大の問題に対応しています。 .. しかし、彼のコーディングスタイルは、「受け入れられた組織スタイル」とは異なります。彼は変更を拒否し、全員を特定のスタイルに順応させるプロセスは時間がかかり、費用がかかります。それで？

私が知っているスーパーハッカーのほとんどは、彼らのスキルと同程度のエゴを持っています。彼らは組織が彼らに順応することを望んでいます。したがって、コーディングスタイルの標準はコーディングスタイルガイドラインのようなものにする必要があります。そうすれば、このキラーハッカーの男に、スタイルの逸脱を伴う非常に高速で驚くべきコードを書き続けることができますが、ステータス、彼らはルールに従う必要があります（あるいは彼の後をきれいにするのを手伝います）。

もちろん、これは管理の悪夢ですが、一般にハイテクの人々を管理することは、とにかく猫を放牧するようなものです。したがって、ほとんどの企業には「スタイル標準」ではなく「スタイルガイドライン」があります。また、すべての企業でスタイル違反が発生するため、ビルドが失敗せず、コードレビューも自動的に失敗しません。あなたが持ちたい管理の問題を決めることができます-スーパースターハッカーを許可して「ガイドライン」を作成するか、スーパースターを失い、より一貫したコードスタイルを設定します。

だから、私はこの文書とこの質問の冒頭の引用から何かを誤解していますか？コーディングスタイルを本当に無視できるのでしょうか？

場合によります。

私が現在いる場所にはスタイルガイドがなく、大したことではありません。プログラマーの間には若干の違いがありますが、読みやすさ、発見可能性、一貫性に意味のある方法で影響を与えるほどではありません。そして、私たちには、チームの新しいメンバーが一列に並ばないように強制するのに十分な大きさのグループと十分に強い文化があります。

以前の会社では、急速に成長しており、言語とそのイディオムに不慣れな人がいました。その会社では、人々の流入は良い執筆を強制する文化がなかったことを意味した。そして、この言語に慣れていない人たちは、調整するものがたくさんあることを意味しました。そこ自動化されたスタイルチェッカーは、調整を行う最も効率的な方法だった、と実際の書かれたガイドは、私たちの期待に新しい人々を訓練するための最良の方法でした。

個人的には、スタイルガイドにはあまり関心がなく、スタイルの自動適用にはあまり関心がありません。その人が基本的なイディオムさえ理解できないのなら、なぜそれらをプログラマーとして採用しているのですか？そして、彼らが非常に悪いチームプレーヤーであり、他の人が作業するのが難しいと感じるコードを継続的に書くのであれば、なぜそれらを採用するのですか？

これは、コーディングスタイルを最適に管理する方法の文字通りの解釈ではなく、心理的な策略です。チーム/会社/マネージャー/リーダーの権威主義を軽減します。私は個人的ではなく、状況的な例外にもっと焦点を合わせます。コーディングドキュメントに関係なく、目標は読みやすくすることです。必要と思われる場合は、混乱を招くコードに対処し、変更する必要があります。小さな退屈なものを処理するツールがたくさんあるので、それらを使用してください。

すべてのルールには例外があります。人々に「いくつかの」小刻みの部屋を与えます。コーディングスタイルのルールを受け入れることに誰もが関与していなければならないほどです（新しい人を歓迎します）。多くのものは白黒ですが、いくつかは解釈に開放されています。

目標は、すべての小さな詳細や解釈を争うのではなく、全員をコーディングガイドラインの精神に関与させることです。

はい、コーディングスタイルのドキュメントを使用する意味がなく、プロと成人の開発者が違いを知ることを許可する必要があります。

編集内容に基づいて、正しい目標を目指します。

スタイルガイドを使用することには多くの利点がありますが、私の意見では2つの最も重要なことは、チームメンバー間のコードの可読性と「愚かな」コミット（空白のみ、余分な行など）の欠如です。

目標を達成するために、選択（または作成）されたスタイルガイドは、シンプルで順守しやすいものでなければなりません。本当に必要なものに集中してみてください。リンターを幸せにするためだけに、コードの巨大な見本を書き直さなければならない人はいません。しかし、まだいくつかの利点があります。

チームメンバーがスタイルガイドを承認していることを確認してください。あなたは彼らをそれに拘束し、彼らが同意するか、それが永遠の闘争であることを確認するつもりです。

スタイル違反が「失敗」ではなく「警告」であることを確認し、違反が失敗に該当するかどうかを人間に判断させます。その理由は簡単です。シンプルなワークフローを信じています。「テスト」フェーズのどこかで「失敗」が発生した場合、本番環境にプッシュできません。私は安全のために使用しています。ホットフィックスでさえ、テスト段階を経る必要があります（ただし、より短い段階です）。誰かが「ではなく」を使用したため、重大なバグ修正をプロダクションにプッシュしないと本当に言うことができますか？それぞれの代わりにforループを使用するとどうなりますか？マシン（リンター）ができない決定であるため、必ず人間を置き、警告を判断し、マシンが障害をスローしないようにしてください。

スタイルガイドを無視することに関して、あなたはケースバイケースでそれを判断しなければなりません。「偏差」に本当の理由があることを確認してください。彼らが現れます。レビュー担当者の仕事は、些細な理由ではなく、逸脱から正当な理由があることを確認することです。

ここでのムード音楽は、受け入れられている知恵がコーディング標準が間違っているか不完全であるということである場合、開発者が困難なプロセスを経るのではなく一般的に合意している場合、2つの悪の少ない方であると思うドキュメントが変更され、再レビューされました。

また、昨年のコード標準の施行ポリシーは、通常、物事が現在行われている方法ではないことに注意する必要があります。

昔は、開発者のデスクの最後に本を置いて、彼のコードがセクション34.5.5767に違反している理由の章と節を引用するだけです。

現在、静的なコード分析と自動ドキュメント作成ツールがあり、コード標準の面倒な作業の多くを取り除きます。

これらすべてに失敗した場合でも、開発者に投げ返すことも、コードレビューで上げることもできますし、必要に応じて自分で変更することもできます。

質問の中心は、2つの引用符の調整です。treecoderが書いたものは、一般的にあなたの質問に答えると思います。これは、スタイルガイドラインを記述する際の指針となります。

より具体的には、コーディングスタイルのガイドラインを設定する責任があるため（これはドキュメントライターであるため、これは私の仮定です）、何がオプションであるかを決定し、あなたの個人スタイルにどの程度柔軟性を持たせるかを決定しますチーム。必要に応じてフィードバックを受け取ります。しかし、ガイドラインが制定されたら、それらに固執します。

そのため、次のように見える2つの矛盾を調整できます。

ガイドライン文書が完成する前に、スタイルの意思決定者としてあなたに宛てられた最初の引用を考えてください。特定のスタイル標準がチームで機能しない場合、これは「強い個人的な反対」とみなされ、ガイドラインに反映されます。

文書が完成したら、チームに宛てた2番目の引用を考えてください。チームのガイドラインを設定し、ドキュメントを作成したら、チームのすべての開発者がスタイルガイドラインを順守することが重要です。

コーディングスタイルがあれば、人々がどのようなコーディングスタイルを持っているかは重要ではありません。会社がコーディングスタイルを主張する場合、彼らは開発者の約49％のつま先を大きく踏みます。

問題は、多くの開発者が会社の一般的な標準にコーディングスタイルを適応させることを気にかけないことですが、会社の政治を熟知している（または単に気にかけている）人々から多くのことを言われていることです。

つまり、コーディングスタイルの標準を作成することは、膨大な時間の浪費、無限の議論の源、無限のresりの原因となり、全体的に膨大な時間とエネルギーを浪費することになります。

他の多くの人がこのフォーラムで行っているように、私は長年にわたってコードスタイルのガイドラインに取り組んできました。これには、私が嫌いだと思う格闘スタイルガイドと、スタイルガイドを使用してスタイル全体を読みやすくするために他の人にスタイルガイドを使用することを奨励することの両方が含まれます。

企業は共通のコーディング標準の恩恵を受けています。企業向けのソフトウェアを開発する際には、前の世代のコードを取得するために新しい開発者をどのように訓練するかなど、考慮すべき重要なことがたくさんあります。コードを書いているとき、あなたはいつもこれについて考えているわけではありません。実際、多くのコーダーは、他の人が行ってから5年または10年後にどのようにコードにアプローチしたいかを考えさえしないことを選択します。コーディングスタイルガイドは、企業がこれらの5年と10年の目標に焦点を当てる方法であり、開発者がより大きなスキームで作業しやすくします。

一方、コーディングスタイルガイドは、完璧なコーディングスタイルを開発して書き留めることができないため、不完全であることが有名です。実際に、完璧なものを作ろうとすると数学的な証明が失敗し始めるおかしなケースに出くわします。したがって、コーディングスタイルガイドが不完全であることがわかります。5年から10年後に必要なものに完全に焦点を合わせているとは限りません。

コーディングスタイルを「強制」した場合、後で価値を上げるために価値を犠牲にすることになります。努力に見返りがあると確信できる場合、これは「投資」と呼ばれますが、コーディングスタイルガイドの作成が不十分な開発者は、開発者の気を散らすことでこれらの「読みやすさ」の利益が支払われることを証明できます。コードから離れます。私の経験では、ソフトウェアが30年または40年使用される可能性のある氷河期の顧客向けのソフトウェアで、強制コーディングスタイルにメリットがあるケースはごくわずかです！

代わりに、コーディングスタイルガイドをマニフェストとして扱うのが最も効果的だと思います：「これは、私たちのグループにとって最良のコーディングスタイルであると信じています」。それは言葉で文書化された流動的な思考の束です。「信じる」という言葉は重要です。信念が変わったら、コーディングスタイルガイドもそれに合わせて変える必要があります。

これが、「強い個人的な反対」の引用の出番です。私が「完璧な」世界と呼ぶものでは、あなたが最高だと思うコードを何でも書いて、その結果で生きます。私たちはプログラミングをしているときに「ソフトな」結果を見落とすことがよくありますが、この場合は重要です。あなたが自分のスタイルで書くことに何の問題もありません。もしあなたが私にあなたに重要で長続きすることを決して与えないことを気にしないならば、開発します。

システム全体をゴルフコースのように考えてください。コーディングスタイルにより、フェアウェイを簡単に進むことができます。あなたがコーディング標準に固執しているなら、私たちは人生ができるだけ簡単であることを確認します。独自のコーディング標準を使用することで、さらにラフになればなるほど、チームでの価値を証明しなければなりません。

月曜日の朝に来て、私たちが1年かけて悩んでいた問題を週末を通して解決し、あなたがあなた自身の「特別な」コーディング標準でそれをやったことを見つけるために、私はあなたに言うつもりはありません修理する。シャワーを浴びに行くように伝えます。あなたの「特別な」コーディング標準が非常に「特別な」場合、エントリーレベルの開発者にコードを「レビュー」して、コードの仕組みに関する知識を広め、読みにくいと思われる場合は彼/彼女がすべきだと言ってもよいでしょう。それを片付ける。あなたはその週末に会社に十分な価値を提供したので、あなたが犯したひどいコーディング標準違反に言及する価値さえありません。

もちろん、このゴルフの比phorには範囲外があります。フォームに新しいフィールドを追加するなど、ランクとファイルのタスクを実行するように依頼し、マクロを定義するような怪しげな文字を使用して、フォーム入力コード全体を特定のスタイルに合わせてリファクタリングすることにしますそして、スタック交換から学んだばかりのいくつかのひどいテンプレートメタプログラミング手法は、戻って修正するように求められます。あなたが行動することを選んだ、それらは結果です。

（免責事項：私はこの実装を完全に書いてis_base_of、些細な作業を解決し、上級開発者から得たすべての地獄を獲得しました。それは価値があると言います。このパターンがC ++仕様の7つの無関係な部分のようにくっついて驚くべきことをしている様子を見てください。上級開発者の皆さん、それboostをこの特定のプロジェクトに禁じるのです！）

Bestは、ほとんどすべての下降IDEの組み込み機能である自動コードフォーマッタを使用しているようで、多かれ少なかれ普及しているプログラミング言語のほとんどに存在するはずです。これにより、コードレビュー中の多くの不要な作業や摩擦が静かに排除されます。

コードの新しく作成されたセクションにフォーマッターを適用する習慣を開発することをすべての開発者に要求することは完全に合理的です。

最悪なのは、既存のコードフォーマッタがサポートしていないカスタムコーディングスタイルを要求することです。

比較的まれなケースでは、フォーマッターが本当にひどくこれを行う場合、一部のセクションが異なってフォーマットされる場合がありますが、通常はフォーマッターを調整してすべてのフォーマットを改善することをお勧めします。

フォーマッタがサポートできない便利なルール（たとえば、変数に名前を付ける方法）がありますが、これらだけが残っていれば、比較的簡単に従うことができます。

実際のソリューション（哲学だけでなく）

コードコメントがリンティングをオーバーライドできるようにし、必要に応じてそれらのコメントのリストをコンパイルします（todoコメントでよく行われます）

開発者が規約の外で明確にかつ理由を持って作業できるようにします。また、人間によるコードのレビュー中に、必要に応じて精査することができます。