私たちのコーディング標準の1つが嫌いで、それは私を狂気にさせます、それをどのように処理するのですか？[閉まっている]

免責事項：タイトルが示すほど誇張されていませんが、それでも私を不快にします。私は正直に言いたいだけなので、一粒の塩でそれを取る。私が話しているコーディング標準について話しているふりをしてください。

編集：私はそれが好きではないという事実は、私はそれを使用したり、それを強制しないことを意味するものではありません。

私は、あなたが好きではない標準を乗り越える方法の精神でこの質問をすることを決めました、それがどのように変更できるかをよりよく議論する方法の助けを得るためではありません（この最後の部分に関するコメントは大歓迎です）。その上、私は大企業で働いていますが、これほど長く生きてきて、ほとんど問題にならないような変化は起こりそうにありません。

標準は、専用線の開始中かっこ標準です。

somefunction()
{
    //...
}

*明らかに優れた*の代わりに（冗談/欲求不満の音に注意してください）：

somefunction() {
    //...
}

標準に対する私の個人的な主張：

• コードが肥大化する：余分な不要な行
• 入力が難しい：これはおそらく私が標準に苦労しているだけかもしれませんが、余分なキーストロークがそれほど悪くないことは知っています。
• 読みにくい：関数宣言、ifステートメント、または他のスコープスタッキングステートメントの読み取りを開始しますが、開き括弧を探す必要はありません。この標準のネストされたブロックは、何らかの理由で私を怒らせます。
• Microsoft IDEのバックグラウンドから来た人々が使用します。パラダイムによってそれを取り入れるだけでなく、標準の背後にある議論された理由（またはそれ以上）があるべきだと思います。

彼らの議論（および内部的に彼らに反論する私の方法）：

• ブロックの開始位置と終了位置がすぐにわかるので読みやすくなります。ブロックの所有者がわからない場合、ブロックの良さはわかりません。逆読みする必要があります。
• 私はMicrosoft IDEでそれを使用し、それが好きでした：うーん...大丈夫？
• それは標準にあります：* cringes *

私は特定の基準に対して意見を述べる姿勢に苦しんでいる唯一の人ですか？、これらをどのように乗り越えましたか？この特定の基準がどうあるべきかについてのあなたの意見は何ですか？

これを乗り越えたいなら、トーバルズによる引用がありました：

悪いプログラマーはコードを心配します。優れたプログラマーは、データ構造とその関係を心配します。

ここで、コード標準で強制されるブレーススタイルのような些細なことを心配するプログラマをどこに置くかを考えてみてください。それ以外の場合、コードベースは非常に手付かずであり、議論する価値がある唯一の問題はブレースだけですか？

好きな人もいれば嫌いな人もいます。いずれにせよ、誰かがイライラするでしょう。今回はあなたの番です。それを吸い上げて、仕事を続けてください。

チームの標準は文書化されていますか？もしそうなら、スタイルガイドに理由はありますか？正直なところ、私はそれを何回も吸い上げて、実際の仕事を終わらせなければなりませんでした。悪い問題がありますが、私はあなたを感じています-それはまだランク付けされています（ちなみに、スタイルについてはあなたに同意します）。

私がそれを乗り越えたのは何ですか：

1. 単一のスタイルには（それが何であるかに関係なく）実際のメリットがあることに気付きました。または、少なくとも多くの人々がそう思う。
2. ちょうどあなたがやったことを正確に、それが間違っていると感じる理由を書き出してください。そうすれば、あなたは将来議論をうまく立てることができます。
3. 神のためにスタイリングツールを使用すると、正気が失われます。 ReSharperの、CodeMaid、StyleCop、JSLint、Checkstyleは、など ...でも、Visual Studioがあなたのためにそれを行います。
4. このプロジェクトに力を入れて、標準を設定できる次の段階に備えましょう。

ある規約が他の規約より優れていることは、明らかに明らかにarbitrary意的です。

あなたが直面する読みやすさの問題、またはチームメイトがあなたの標準に直面することは、変化に対する心理的な抵抗にすぎません。

客観的な読みやすさの議論は、コードベース全体で*一貫性*を支持しています。

バックあなたがいた時に考えてみてくださいあなたはすべてのそれらの年前に過剰反応していることをあなたは右の何かについて、あなたは間違っていたことに気づい時間をかけたこと、または少なくとも。あなたが再び間違っているかもしれないという可能性を考慮し、あなたを納得させるために新しいコーディング標準またはプロセス時間を与えてください。

私の独自の基準怒り、私はコーディングにかなり新しいだった（私のキャリアの中に5年と言う）マルチワードの識別子であるべきかどうでしたWrittenLikeThisかwritten_like_this。私は自分がどれを言ったのかさえ言うつもりはありませんが、ポイントは、しばらくしてから側を変え、しばらくしてからどちらにしてもかまわないということです。

中括弧で説明する標準的な違いは、ほとんど任意です。両方の方法が等しく良い方法であり、企業にとっては、誰もが同じことをしている限り、それはすべて良いことです。

あなたが話している「明らかに優れている」とは、人々が「慣れている」ことについて話すときに話す一種の優れたものです。

あなたはすぐにそれに慣れるでしょう、そして1年かそこらで、他の方法は「明らかに優れている」でしょう。

要するに：それに対処する。

この特定の主題は、あるスタイルを他のスタイルよりも好む人々の間の宗教戦争に相当します。あいまいな人はほとんどいません...

最終的に、どちらも正しくなく、どちらも間違っていません。

スタイルガイドとコーディング標準はさまざまな理由で存在します。重要な側面の1つは、明らかなエラーの数を減らし、保守性を向上させることを目的としたレイアウトの均一性を確保することです。

特定の基準に反する意見を述べる姿勢と格闘しているのは私だけですか？

短い答えは「いいえ」です。あなただけではありません。しかし、心配するべきより重要なことがあります。意見を述べた標準であっても、常に妥協点があります。私にとって意味のないC99とC12になった側面を目撃してください。

MISRA-C（私が直接影響力を持っている）でさえ、個人的には同意しない項目が含まれていますが、他の人が正当化を感じる理由を理解できます。

これらをどうやって乗り越えましたか？

そして、そこに答えがあります-あなたが個人的にそれを好きではない理由に焦点を当てるのではなく、同意した人/人がなぜそうしたのかを試して理解してください。

前の問題に対処するために、規則が通常導入されます（馬が一種の方法でボルトを締めた後、安定したドアを閉める）。ルールがまだ意味をなさない場合は、標準の所有者と話し、それらを「教育」してみてください。

私はあなたがちょうどそれに取り組む必要があると思います。私は自分の意見であなたのノートに対処しようとします：

• 膨張コード

  単一のクラスで数百のメソッドを記述している場合を除き、コードの1行追加してもコードが肥大化することはありません。繰り返しますが、1つのクラスに何百ものメソッドがある場合、まったく別の問題が発生します。

• 入力が難しい

  これについては、これ以上異議を唱えることはできません。とにかく次の行に戻るには、リターンキーを押す必要があります。入力が難しいのはどうですか？

• 読みにくい

  コードの各行には特定の機能が必要だと思います。これに続いて、メソッド名を1行で定義し、次に開き括弧と閉じ括弧を別々の行で定義する必要があります。

• MS IDEのバックグラウンドを持つ人々が使用

  うーん.....大丈夫？

要約すると、この標準にデフォルト設定されているIDEを使用しているため、他の種類の開発者とは対照的に、.Net開発者であることをしているように見えます。

特定の基準に反する意見を述べる姿勢と格闘しているのは私だけですか？

もちろん違います。コーディング標準を決定する会議は恐ろしいです！彼らは何時間も引きずり込み、参加者は自分の好きな（そして私のものを除いて常に間違っている）特異性を標準に刻み込むことに個人的に投資します。最後には、誰も結果に満足していません。コーディング標準会議よりも悪いことがある場合は、標準の決定に続く数ヶ月の正式なコードレビュー会議です：一部の人々は標準を採用しようとしますが、他の人は（意図的またはそうではなく）それを無視し、以下のようなフィードバックの時間：コーディング標準は明らかにそれが上であることを言うとき、あなたが同じ行に左カッコを配置ライン132、142、145、181、195、およびSillyFileConverter.cppの221で、次の行！

これらをどうやって乗り越えましたか？

独自の方法で、会議が役立ちます。条件付きと同じ行にオープニングブレースを残した男に完全に同情したとしても、それでも、それを吸い上げて愚かな基準に従わないことであなたの時間を浪費していることに腹を立てます。その男が呪術師であり、同じことを何度も繰り返すと、さらに面倒になります。その振る舞いに悩まされることは、あなたが好むものとは少し異なるスタイルで書くことを正当化することをはるかに簡単にします- 結局のところ、あなたは確かにその男になりたくありません。

あなたが間際の正式なコードレビューを受けていない場合でも、規格への準拠のためにあなた自身のコードをレビューすることを試みることができます。標準についてどう思うかは問題ではなく、自分が書いたものを標準が言うことと比較しているだけです。順守に失敗するたびに自分自身を鳴らすと、標準の採用を支援するために必要な否定的なフィードバックの一部を提供する可能性があります。

このようなことで、リリパットのガリバーを覚えています。リリプティア人はゆで卵を開くために終わりを告げる戦争を戦っていた。（元のビッグエンディアン、リトルエンディアンの戦い）。

自分自身を笑う機会と考えてください、彼らは実際にビジネスで十分に頻繁に来ません。

あなたの特定の例は、一部の人が同意する人とそうでない人がいるため、残念です。たとえば、あなたの議論に反対し、他の多くの人も同意すると確信するように、他の多くの人もそうなると確信しています。主観的であるため、質問は閉じられるべきだと思わせます。

しかし、あなたが同意しない標準をどのように扱うかについての質問は、もっと答えられる可能性があります。答えは、スタイリングのガイドラインが存在し、合意され、使用されている場合、笑い、耐え、対処するだけだということだと思います。一貫性を持つことがより重要であることを考慮してください。ガイドラインが不正確または間違っている場合、変更の議論がある可能性がありますが、これは文体的であるため、個人的な好み以外に議論はありません。

私はもともとJavaのバックグラウンドから来たので、あなたが言及した標準に従いました。次に、嫌いなスタイルが使用されるC ++とC＃に移動しました。しかし、正しい答えも間違った答えもありません。さらに重要なのは、全員が標準を遵守することです。コーディング標準がこのような文体であり、明らかに間違っていない場合、それを主張しようとすると、チームに摩擦が生じるだけです。

フォーマッター+チェックインフックは良い出発点です。しかし、それは十分ではありません。あなたが書くことは、あなたが一日中見つめることほど重要ではないからです。状況によっては、EmacsのGlassesモードのアプローチ-ファイルをスタイルに保ちながら、スタイルに近づけて表示する-が魅力的です。

これで私の経験- 、それがために書かれた正確な問題に直面してCamelCapsVSはunderscore_separated-それはすぐに役に立つよりも迷惑になったということでしたが、数週間のためには、（しぶしぶ）に私の移行を平滑化し、同社のスタイルを受け入れるだけでなく、コンセントを提供します怒りを伝えるために（「ああ、嫌いだ。もう一度設定を調整させて...少なくともそこで何かをやった」）;-)

とにかく、メガネモードは、ブレースの配置に対応していない、あなたはおそらくEmacsのを使用していない、とあなたのエディタで独占的にコードを読んでいない:-(
しかし、最後の点はチャンスもある-あなたがあれば読んで、ほとんどの時間でのコードを独立したツールであるため、それをハックして、往復の再フォーマットノイズを心配することなくスタイルを変換できます-それは読み取り専用です！特に、Webインターフェースでコードを読み取る場合は、Greasemonkeyを使用してください。

軽度の緩和のための簡単なアイデアを次に示します。

• 失われた画面行を取り戻すために、幅は広いがそれほど高くないフォントを選択します。

  • 可能であれば、フルスクリーンをより頻繁に使用します。

• 中括弧を微妙な色（およびより小さいフォント？）で強調表示するように設定し、他のコードよりも見えにくくします。インデントは、特に読むために十分でなければなりません。{行の空スペースで...

• エディターは、終了時に一致する開きブレースをハイライトするようにしてください}-思わず間違った場所に目が入った場合に少し助けになるかもしれません。

• 「入力するのが難しい」こと：本物のエディターを取得し、を押すと自動的に新しい行を開くように設定します{。

それと一緒に暮らす。

これは明らかに化粧品であり、コードの品質や開発者としての生産性については何も変わりません。議論をやり直す価値はありません。

この種のコーディング標準では、コードベース全体の一貫性と、特定の（理性的な）「宗教的」アプローチに対する可読性をいつでも選択します。

それほど重要ではない問題について、チームメンバーの過半数の民主的な決定と考えると、それを乗り越えるのに役立ちます。

それが標準です：

http://doh-san.blogspot.com/2005/10/five-monkeys.html

「その標準」と言う人のほとんどは、「5匹の猿」の原則に従っています。

先に進み、必要なスタイルを使用してください。次に、いくつかのコードビューティファイヤ を使用して標準形式のコードを変更するか、コードをスタイルから指定された標準スタイルに変換する独自の小さなアプリケーションを作成します。コードをチェックインする前に、ビューティファイヤを使用してください。
また、逆の操作を行って、チェックインコードを標準形式から使用中の形式に変更することもできます。