最近、GitHubで多くのオープンソースRuby（またはその大部分がRuby）プロジェクトに遭遇しました。Rubocopなどのコード分析ツールで確認すると、多くの違反が発生します。

現在、これらの違反のほとんどには、単一引用符の代わりに二重引用符を使用することが含まれています（補間ではない場合）、レベルごとに2スペースの規則に従っていない、80文字の行長規則を超えている、または複数行のブロックを使用{し}ています。

[The] Rubyスタイルガイドでは、実際のRubyプログラマーが他の実際のRubyプログラマーが保守できるコードを作成できるように、ベストプラクティスを推奨しています。〜ソース：Rubyスタイルガイド

小さくて簡単に修正できますが、オフェンスを修正してプルリクエストを行うことで、オープンソースプロジェクトのコーディングスタイルを変更することは適切ですか？私はRailsのようないくつかのプロジェクトは、ことを認め化粧品の変更を受け入れないと、一部がRubocopが実行されたとき（Railsが例えば80,000犯罪を生成し、一度にすべての「修正」にあまりにも大きいです-に関係なく、彼らは独自の小さなセット持ってコーディングを貢献する際に従うべき規則）。結局のところ、Rubocopのようなツールと一緒にRubyスタイルガイドがあります。

人々は一貫性を高く評価しているので、このような変更を加えることは、Rubyコミュニティ全体にとって良いことです。

[Rubyスタイルガイドの著者]は、どこからともなくすべてのルールを思いついたわけではありません。それらは、主にプロのソフトウェアエンジニアとしての幅広いキャリア、Rubyコミュニティのメンバーやさまざまなメンバーからのフィードバックや提案に基づいています「Programming Ruby 1.9」や「The Ruby Programming Language」など、高く評価されているRubyプログラミングリソース。〜ソース：Rubyスタイルガイド

コミュニティコーディングスタイルの規則とベストプラクティスに従っていないため、基本的に悪いプラクティスを奨励していませんか？

メンテナーに尋ねてください。

コーディングスタイルは非常に主観的な議論であり、80文字の最大行長などのルールはかなり主観的です-一般的な合意は短い行の方が読みやすいことであるはずですが、80は今日の画面サイズとIDEの一部にとっては制限が厳しすぎるかもしれません。

他のルールも意図的に無視することができます。たとえば、開発者は、二重引用符のグローバルな使用を自分にとってより適切であると考え、偶発的な補間の「リスク」と解析時間のごくわずかな増加を受け入れることをいとわないかもしれません。

また、多くのメンテナーは、レビューするのが退屈であり、エラーが発生する可能性があるため、コーディングスタイルの大幅な変更を好みません。たとえば、意図的な補間が含まれていて、二重引用符を使用する必要があった場合でも、文字列を単一引用符に切り替えることができます。メンテナーは、スタイルの変更によって新しいバグが発生しないことを確認できるように、実際のコードで作業しながらスタイルのクリーンアップを行うことを好みます。

主に動機付けられているのは、rubocopツールとRubyスタイルガイドの権限を尊重しているためです。彼らはすでに独自のスタイルを持っており、それに慣れているため、変更はプロジェクトで作業しているすべての人に影響を与えます。特にプロジェクトが大きい場合、それは多くの作業です。

メンテナーの動機を考慮してください。彼らは、（おそらく）バグ修正、バグ報告、作業コード、よく書かれたドキュメントを提出することによって、新しい人々が参加することを望んでいます。あなたが現れて「あなたはルボコップに犯罪がある」と言うと、彼らは「ああ、良い人、負荷を共有するのを助ける新しい人」とは考えません。何をすべきか？"。

オープンソースプロジェクトは実力主義である傾向があります：あなたはあなたの仕事の質に基づいて尊敬を得ます。あなたが現れると偉大なことを行うとした場合、その後、あなたのスタイルの懸念を持ち出す、彼らが聞く可能性が高くなり、彼らはまだ何も言わないかもしれませんが。「トークは安い、コードを見せて」というオープンソースがあります。

常にドグマに対するプラグマティズム。コーディングスタイルガイドは、特に陰湿な悪の形態であり、建築上の懸念から注意を引き付けて、シングル/ダブルクォートのような軽薄なナンセンスに注目させます。自問してください：それは本当に違いを生むのでしょうか？

彼らはある程度までは良いかもしれませんが、2番目にほとんど宗教的な熱意でそれらを扱うと、あなたは行き​​過ぎになりました。それらは、事実ではなく、ガイドライン、提案、意見です。

それらは無視されるべきですか？いいえ、ツールを使用して、何を調べる必要があるかについての一般的なアイデアを得るメリットがありますが、それ以上はありません。

ジュニアタイプが意見と事実を混同する頻度は不思議です。

これらの変更をプルできるのは、フォーマットを修正する未解決の問題がある場合のみです。それ以外の場合は、独自のブランチを開始します。作成者が、読みやすいという理由だけで、より多くの人がブランチを使用していると判断した場合。それらはそれ自体でブランチにマージされますが、更新をマージし、常にフォーマットを修正することでブランチを維持する準備ができています。

プロジェクトがあなた自身のブランチを維持し続けるのにあなたにとって十分に重要でないなら、そもそもクリーンアップする価値はありませんでした。

プルリクエストは、作成者が個人的に取得できます。それは批判を提供するメカニズムではなく、すべてのコードを再フォーマットすることは批判とみなされる可能性があります。

独自のブランチを維持したくないが、プロジェクトに貢献したい場合。新しい問題を開き、現在の形式が問題の原因である理由を説明してから、作成者に問題を解決するよう提案します。著者が同意すれば、彼らはあなたに問題を割り当て、あなたはプルリクエストを行う許可を得ました。

GitHubで横行する問題であることに私も同意するというテーマに触れました。フォーマットは別として、アノテーションを誤って使用し、多くのIDEで大混乱を引き起こすプロジェクトがいくつかあります。私のIDEで警告メッセージを伝播する非推奨のフラグを誤って使用する3つの主に人気のあるプロジェクトを考えることができます。プルリクエストを送信して修正しましたが、作成者は同じIDEを使用していないため、プルリクエストは無視されます。

分岐、マージ、修正が唯一の解決策のようです。

Rubocopサイト自体から取得（強調鉱山）：

Python開発者には素晴らしいプログラミングスタイルリファレンス（PEP-8）があり、Rubyのコーディングスタイルとベストプラクティスを文書化した公式ガイドはありませんでした。

ご理解ください：

公式Rubyスタイルガイドはありません

スタイルガイドが悪いと言っているのではありません。しかし、公式ガイドがないだけでなく、スタイルガイドを持つことは、個人、プロジェクト、チーム、企業レベルで行われる選択です。スタイルガイドは、心理学用語を使用すると、「グループ内の社会的規範」です。

それはあなたにとって何を意味しますか？グループ内のメンバーと見なされていない場合、それはあなたまたは他のWebサイトが言うことを意味しますが、グループに影響を与える可能性はほとんどありません。あなたがその特定のプロジェクトに積極的で尊敬されている貢献者でない場合、おそらくあなたの提案は無視されるか、せいぜいスタイルガイドを持つことに関する以前の考慮事項を思い出させるでしょう。最悪の場合、それはs辱として、または侵入者または自転車置き場として、それが属していない場所に鼻を突き刺すことになるでしょう。

スタイルガイドを提案することはできませんか？

実際、それはあなたがやりたいことのようです。スタイルガイドの価値を信じ、一貫性を高く評価し、統一されたスタイルガイドラインへの献身のために伝道したいのです。

本当に明確である限り、それはあなたの目的であり、達成したいことです。特定のスタイルガイドを信じて、それがThe One True Style Guideであると信じている場合、または少なくとも無法者が練習中に走り回っているものよりも優れている場合、それも問題ありません。

しかし、人々が認めていないのは、彼らの行動が正当な権威とは考えないソースからの非公式で拘束力のない大部分がarbitrary意的な規則に準拠していないことです。それがあなたがやろうとしていることである場合、または単にそれがあなたがしていると知覚されているものである場合、あなたはより少ない「レッドカーペット治療」、そしてより多くの「槍と大きな沸騰鍋を持つ怒っている先住民」を得るでしょう処理。

ここで別の意見を述べるには、多くの場合、そのような変更を歓迎します。オープンソースプロジェクトには多くの著者がいる傾向があります。多くの場合、「コーディングスタイル」はありません。スタイルは、問題のコードを書いた人がたまたま使用したものです。あるファイルが別のファイルと異なる人によって書かれた場合、スタイルも異なる場合があります。コンセンサススタイルがあるプロジェクトでも、彼らが定期的にこのスタイルをチェックしない限り、しばしば使用されません。

私の経験におけるこの一般的な例は、誰かがスタイルに関して比較的低品質のプル要求を介してコードを提供する場合です。ただし、コードは機能する場合があります。これについては、人によって意見が異なります。スタイルが適切でない限り、プルリクエストのマージを拒否する人もいます。コードが機能する限り、気にしない人もいます。良いスタイルを好む人もいますが、「ここの空白を修正する」というコメントで投稿者を怖がらせたくありません貢献者を怖がらせるかもしれないように感じるので、コードベースの良いところです）。

そのため、表示されるスタイルがプロジェクトで必要なスタイルであると思い込まないでください。実際、それはおそらく一般的にオープンソースに貢献するために一般化することができます。オープンソースプロジェクトが持っているコードが望んでいるコードであると仮定しないでください。

ただし、次の点に注意する必要があります。

• 一部の人々はスタイルについて宗教的です。彼らが動揺したくないことが明らかになったら、気にしないでください。

• これは巨大な 自転車置き場の問題です。みんなと彼らの兄弟は、これらのことについて意見を持っています。このため、このようなプルリクエストをマージするのは難しい場合があります。

• また、マージの競合が非常に迅速に発生するため、このようなプルリクエストをマージすることは困難です。基本的に、変更したコードベースの一部が変更された場合は、たとえ些細な方法であっても。

「最初に尋ねる」アプローチに固執します。彼らがそれに対してオープンであり、あなたがプルリクエストを最後まで固守したいと思っているなら、それを続けてください。

私は以前はスタイルガイドを作成するのが大好きでしたが、Rubyの状況を考えると、「先に進みました」。

基本的に、私は自分が取り組んでいるものと一緒に暮らし、そうでなければ多くの仕事から学んだ一般的な慣習に従います。

私が選んだ言語であるRubyの場合、スタイルを普遍的に受け入れられている、一般に受け入れられている私の好みとベストプラクティスに（私の頭の中で）分けました。広く受け入れられているもの私は、問題または機能ブランチのリクエストの変更リクエストの一部として変更を送信する場合があります。

各スタイルの例（私の意見では）：

Rubyで広く受け入れられています：

• タブではなくスペース
• 2つのスペースインデント
• method_names_use_underscores
• 定数はCapsで始まります。

一般的に受け入れられます：

• 必要でない場合は括弧を使用しないでください
• { }1行のブロックとdo end複数行のブロックに使用します。
• CONSTANTS_ARE_IN_ALL_CAPS
• 式が1行に収まる場合は、述語（cond ? true : false）を使用しif thenます。

個人的な好み：

• 120文字の行の長さ
• case whenステートメントは、caseステートメントから2インデントされます。
• doubleが必要でない限り、一重引用符を使用します。

契約なし：

• ケースステートメント
• 行の長さ

ベストプラクティス：

• 小さなメソッド、可能であれば<= 5行。
• 小さなクラス、可能であれば<= 100行。
• 定数を避ける
• コードにはテストがあります

最後に、他の人が詳しく述べているように、最初に尋ねるべきです。結局のところ、スタイルの鍵は開発者間のコミュニケーションと他者に対する感受性です。たとえば、オープンソースプロジェクトでスタイルを変更する場合、最初の1つまたは2つの実際の機能またはバグ修正のためにプルリクエストを行うことがよくあります。メンテナが私を知っていて、私が貢献してきたことを認識したら、その後、私はスタイルの変更を提案することがあります。私はそれらを提案するだけです。たとえば、「プロジェクトxで別の機能を実行しているときに、いくつかのファイルに4つのスペースインデントがあることに気づき、それらを2に変更できるかどうか疑問に思っていましたか？」

小さくて簡単に修正できますが、オフェンスを修正してプルリクエストを行うことにより、オープンソースプロジェクトのコーディングスタイルを変更しても大丈夫だと思いますか？

要するに、いいえ！

もちろん、ここではこれらは単なるスタイルの問題であり、実際のバグではないと想定しています-後者のプルリクエストは常に賢明です（IMO）。既にそれを維持している人々と接触していない。

ただし、どの言語の中にも、スタイルガイドとは異なるものの好みがあり、良くも悪くも、あなたが知らない人やあなたが参加していないプロジェクトにそれらのスタイルの変更を強制しようとする人が常にいます他に何も失礼ビットとして全体で来ることができなかった場合。結局のところ-要求が受け入れられた場合、実際には何を達成していますか？おそらく、あるプロジェクトのメンバーがスタイルを別のものに変更したい場合、彼らはすでにそれを行っていたでしょう-そして、あなたがそのリクエストでやっていることは、必ずしもうまく機能しないスタイルを強制することです既存のメンバー用。

スタイルの「修正」以外の方法でプロジェクトに貢献したい場合、これはわずかに変わります。プロジェクトの作業方法についてメンテナーと対話をしたいが、非標準のスタイルが難しいと思うなら、それは問題ありません。しかし、スタイルの変更のみを含む多数のプロジェクトのプルリクエストを盲目的に作成するだけではありません。

どんな変更でも、バグを引き起こす可能性があり、コードの印刷上の書式設定を変更することさえあります。
したがって、有効なビジネスケースがない限り、コードを変更する必要はありません。また、「コードは見た目がよくありません」または「コードがコーディング標準に従っていない」は有効なビジネスケースではありません。リスクは単純に大きすぎます。
さて、とにかくソースファイルに大きな変更を加える場合、標準に沿ってファイル全体をプルすることは受け入れられるかもしれませんが、ほとんどの場合、小さな変更を行うことになります。既存のコードがコーディング標準に従っていない場合でも、既存のコードに合わせます。
ちなみに、コードはコードジェネレーターの結果である可能性があり、場合によっては再生成されます。コードジェネレーターは、いコードを生成することで有名です...

ある程度成功している.NETプロジェクトがいくつかあり、ReSharperとStyleCopを使用してコードを処理し、多くのことを「修正」したように見える人々からのPRがいくつかありました。いくつかの理由により、私はこれらのPRを受け入れません。

• 変更の多くは改善されていますが、それらのいくつかは何らかの方法でコードに悪影響を与えますが、通常はパフォーマンスに影響し、良い部分を選択するのは大変な作業です。
• すべての変更が良性または有益であったとしても、すべてのコミットのすべてのファイルのすべての変更を確認する必要がありますが、それでも時間がかかりすぎます。

それは、誰かがより良いエラーチェックやドキュメンテーションコメントを追加したいなら、私はハートビートでそのPRを受け入れます。

メンテナーがこれらのコーディングスタイル違反を欠陥と見なすか、プロジェクトにコーディングスタイルの異なる標準があるかどうかを調べる必要があります。

別の標準がある場合は、文書化や形式化を支援できます。その後、そのスタイルにいくつかの違反があることが判明する可能性があり、それらを修正することができます。