ベストプラクティスに従わないオープンソースプロジェクトでコーディングスタイルを変更しても問題ありませんか？
最近、私は多くのオープンソースに出会いましたRuby（またはその大部分はRubyでした） GitHub上のプロジェクト そのようなコード分析ツールでチェックすると Rubocop 、大量の offenses を作成します。
現在、これらの違反のほとんどには、一重引用符の代わりに二重引用符を使用する（補間でない場合）、レベルごとに2つのスペースの規則に従わない、80文字の行の長さの規則を超える、または{および}複数行ブロック。
[The] Rubyスタイルガイドはベストプラクティスを推奨しているため、現実の世界Rubyプログラマは他の現実の世界で維持できるコードを記述できますRubyプログラマー。〜 出典：Rubyスタイルガイド
それらは小さく、修正が簡単ですが、オフェンスを修正してプルリクエストを作成することにより、オープンソースプロジェクトのコーディングスタイルを変更することは適切ですか？ Railsのような一部のプロジェクトは 表面的な変更を受け入れない であり、一度に「修正」するには大きすぎるプロジェクトもあります（たとえば、Rubocopの実行時に、Railsは80,000を超える違反を生成します-関係なく、貢献するときに従うべき独自の コーディング規約 の独自のセットがあります）。結局のところ、 Rubyスタイルガイド は、Rubocopのようなツールと一緒に理由があるのです。
人々 一貫性を認める したがって、この種の変更を行うことは、Rubyコミュニティ一般にとっては良いことです）
[Ruby Style Guide]の作成者）は、すべてのルールをどこからともなく思いついたわけではありません。それらは主に、プロのソフトウェアエンジニアとしての私のキャリア、フィードバック、 Rubyコミュニティおよびさまざまな高く評価されているRubyプログラミングリソース、 "Programming Ruby 1.9"などのメンバーからの提案"Rubyプログラミング言語"。〜 出典：Rubyスタイルガイド
コミュニティコーディングスタイルの規則や、基本的にbadプラクティスを奨励するベストプラクティスに従っていないのですか？
メンテナに聞いてください。
コーディングスタイルはかなり主観的な議論であり、80行の最大行長などのルールはかなり主観的です-一般的な合意では、短い行の方が読みやすく、80は今日の画面サイズやIDEでは制限が厳しすぎる場合があります。
他のルールも意図的に無視することができます。たとえば、開発者は、二重引用符のグローバルな使用をより適切に検討し、偶発的な補間と解析時間のわずかな増加の「リスク」を受け入れてもかまいません。
また、多くのメンテナーは、大規模なコーディングスタイルの変更を嫌がります。レビューするのは退屈で、エラーが発生する可能性があるためです。たとえば、文字列は意図的な補間が含まれていて、二重引用符を使用する必要があったとしても、単一引用符に切り替えることができます。メンテナーは、実際のコードに取り組んでいる間、スタイルのクリーンアップを行うことを好みます。そうすることで、スタイルの変更が新しいバグを導入しないことを確認できます。
あなたは主にrubocopツールの権限とRubyスタイルガイドを尊重することで動機付けられているようです。メンテナーは共有しないかもしれません。彼らはすでに独自のスタイルを持ち、それに慣れています、したがって、変更はプロジェクトに携わるすべての人に影響を及ぼします。特にプロジェクトが大きい場合は、多くの作業になります。
メンテナの動機を考慮してください。彼らは（おそらく）バグフィックス、バグレポート、作業コード、よく書かれたドキュメントを提出することで、新しい人々に参加してもらいたいと思っています。あなたが現れて「あなたはルボコップに罪を犯している」と言っても、彼らは「ああ、負荷を分かち合うのを助ける新しい人」とは考えないでしょう、「彼らは誰ですか？なぜ彼は私たちに言っているのですか？何をすべきか？"。
オープンソースプロジェクトは功徳主義になりがちです。あなたは仕事の質に基づいて尊敬を得ます。あなたが現れて素晴らしいことをして、そしてthenがあなたのスタイルの懸念を持ち出すなら、彼らはまだノーと言うかもしれませんが、彼らは聞く可能性が高くなります。 「トークは安い、私にコードを見せて」と言っているオープンソースがあります。
常に、ドグマに対する実用主義。コーディングスタイルガイドは、特に注意を払う必要のない悪の形であり、シングル/ダブルクォートのような軽薄なナンセンスにアーキテクチャ上の懸念から注意をそらします。自問してみてください：それは本当に違いを生みますか？
彼らはある程度までは良いかもしれませんが、ほとんど宗教的な熱狂で彼らを扱う2番目に、あなたは行き過ぎです。それらはガイドライン、提案、意見であり、事実ではありません。
それらは単に無視されるべきですか？いいえ、何を検討する必要があるかを大まかに把握するためにツールを使用するメリットはありますが、それ以上のメリットはありません。
ジュニアタイプが実際の意見をどれほど混乱させるかは不思議です。
これらの変更をプルできるのは、フォーマットを修正するための未解決の問題がある場合のみです。それ以外の場合は、独自のブランチを開始します。そして、より読みやすいという理由だけで、より多くの人々がブランチを使用していると著者が見た場合。これらは独自にブランチにマージされますが、更新をマージし、常にフォーマットを修正することにより、ブランチを維持する準備をしてください。
プロジェクトがあなた自身のブランチを維持し続けるのに十分重要でない場合、そもそもクリーンアップする価値はありませんでした。
プルリクエストは作者が個人的に行うことができます。これは批判を提供するためのメカニズムではなく、すべてのコードを再フォーマットすることは批判と見なすことができます。
独自のブランチを維持したくないが、プロジェクトに貢献したい場合。新しい問題を開き、現在の形式が問題を引き起こしている理由を説明してから、作成者に問題の解決を提案します。作成者が同意すると、問題が作成者に割り当てられ、プルリクエストを行う権限が付与されます。
GitHub で蔓延している問題でもあると私が同意する主題に触れました。書式設定はさておき、誤って annotations を使用し、多くのIDEで大混乱を引き起こすプロジェクトがいくつかあります。 IDEで警告メッセージを伝達する、非推奨のフラグを誤って使用する3つの主に人気のあるプロジェクトを考えることができます。プルリクエストを送信して修正しましたが、作成者は同じIDEを使用していないため、プルリクエストは無視されます。
ブランチ、マージ、修正が唯一の解決策のようです。
Rubocop サイト自体からのもの（私の強調）：
Ruby開発者-Python開発者は優れたプログラミングスタイルリファレンス（PEP-8）と公式ガイドを入手したことはありません、文書化Rubyコーディングスタイルとベストプラクティス。
ご理解ください：
公式Rubyスタイルガイドはありません
スタイルガイドが悪いと言っているのではありません。しかし、公式ガイドがないだけでなく、スタイルガイドを持つことは、個人、プロジェクト、チーム、会社レベルで行われる選択です。スタイルガイドは、心理学の用語を使用する場合、「グループ内の社会的規範」です。
それはあなたにとって何を意味しますか？まあ、あなたがグループ内のメンバーと見なされていないのであれば、それはあなたや他のウェブサイトが言っていることは何でもグループとの関係を保つ可能性が非常に低いことを意味します。したがって、その特定のプロジェクトに積極的で尊敬されている貢献者でない場合は、ほとんどの場合、提案は無視されるか、せいぜい、スタイルガイドの使用に関する以前の考慮事項を思い出させます。最悪の場合、それは侮辱として、または侵入者として、または bikeshedder それが属していない場所に彼らの鼻を突き刺すものとしてとられます。
あなただけのスタイルガイドを提案することはできませんか？
実際、それはあなたがやりたいことのようです。スタイルガイドの価値を信じ、一貫性を高く評価し、統一されたスタイルガイドラインに専念するために evangelize をしたいのです。
それが本当に明確である限り、それは問題ありません。特定のスタイルガイドを信じて、それがThe One True Style Guideであると信じている場合、または少なくとも、これらの無法の異教徒が実践している何よりも優れている場合、それも問題ありません。
しかし、人々が感謝しないのは、彼らの行動が非公式で拘束力のない、主に恣意的な規則に準拠していないということです。それがあなたがやろうとしていることであるとき、または単にそれがあなたがそうであるものであるとき知覚されるそうすることで、「レッドカーペットトリートメント」の効果が減り、「槍と大きな鍋で怒った先住民」の効果が高まります。
ここで別の意見を述べるために、多くの場合、そのような変更は歓迎されます。オープンソースプロジェクトには多くの作者がいる傾向があります。多くの場合、「コーディングスタイル」はありません。スタイルは、問題のコードを書いた人がたまたま使用したものです。 1つのファイルが別のファイルとは別の人によって作成された場合、スタイルも異なる場合があります。コンセンサス・スタイルがあるプロジェクトでも、定期的にこのスタイルをチェックしない限り、使用されないことがよくあります。
私の経験では、これの一般的な例は、誰かがプルリクエストを介して、スタイルに関して比較的低品質のコードを提供する場合です。ただし、コードは機能する場合があります。これについては、人々によって意見が異なります。スタイルが適切でない限り、プルリクエストのマージを拒否する人もいます。コードが機能する限り、気にしない人もいます。一部の人々は良いスタイルを好むが、彼らは「ここの空白を修正」のコメントで貢献者を怖がらせたくありません（私は個人的にはこれらのコメントをすることは常に少し罪があると感じています。それは貢献者を怖がらせるかもしれないような気がするので、コードベースは良いです）。
したがって、表示されているスタイルがプロジェクトで必要なスタイルであるとは、絶対に想定しないでください。実際、それはおそらく一般的にオープンソースに貢献することに一般化することができます：オープンソースプロジェクトが持っているコードがそれが望むコードであると仮定しないでください。
ただし、次のことに注意する必要があります。
一部の人々はスタイルについて宗教的です。彼らがびくびくしたくないことが明らかになったなら、気にしないでください。
これは巨大なbikeshed の問題です。みんなとその兄弟はこれらのことについて意見を持っています。そのため、そのようなプルリクエストをマージするのは難しい場合があります。
また、マージの競合が非常に早く発生するため、そのようなプルリクエストをマージするのが難しい場合もあります。基本的に、変更したコードベースの一部が変更されたときはいつでも、たとえそれが些細なことであっても。
私は「最初に尋ねる」アプローチに固執します。彼らがそれにオープンしていて、あなたがプルリクエストを最後までやりたいと思っているなら、それを求めてください。
私は以前は優れたスタイルガイドを持っていることに大きな関心を持っていましたが、Rubyの状況を考えると、「私は先に進みました」。
基本的に私は自分が取り組んでいるものと一緒に暮らしており、そうでなければ、多くの仕事から学んだ一般的な慣習に従っています。
私が選択した言語であるRubyについても、私は（頭の中で）スタイルを普遍的に受け入れられ、一般に受け入れられている私の好みとベストプラクティスに分けました。普遍的に受け入れられていること私は、問題の変更リクエストまたは機能分岐リクエストの一部として変更を送信する場合があります。
各スタイルの例（私の意見では）：
Rubyで広く受け入れられている：
- タブではなくスペース
- 2つのスペースインデント
- method_names_use_underscores
- 定数は大文字で始まります。
一般的に受け入れられる：
- 必要がない場合は括弧を使用しないでください
- 使用する
{ }1行ブロックおよびdo end複数行ブロック。 - CONSTANTS_ARE_IN_ALL_CAPS
- 述語（
cond ? true : false）if then式が1行に収まる場合。
個人的な好み：
- 120文字の行の長さ
- case
whenステートメントは、caseステートメントから2インデントされます。 - 二重引用符が必要でない限り、単一引用符を使用してください。
同意なし：
- ケースステートメント
- 線の長さ
ベストプラクティス：
- 小さなメソッド、可能であれば5行以下。
- 小さなクラス、可能であれば100行以下。
- 定数を避ける
- コードにはテストがあります
最後に、他の人が詳しく述べているように、最初に尋ねるべきです。結局のところ、スタイルの鍵は、開発者間のコミュニケーションと他者に対する感受性です。たとえば、オープンソースプロジェクトのスタイルを変更したい場合、最初に1つまたは2つの実際の機能またはバグ修正をプルリクエストすることがよくあります。メンテナが私を知っていて、自分が貢献したことがわかったら、その後スタイルの変更を提案するかもしれません。私は推奨だけですが。たとえば、「プロジェクトxで別の機能を実行しているときに、2つのファイルに4つのスペースインデントがあることに気付き、それらを2に変更できるかどうか疑問に思いました。」
適度に成功した.NETプロジェクトがいくつかあり、ReSharperとStyleCopを使用してコードを実行し、多くのものを「修正」したように見える人々からのPRをいくつか持っています。いくつかの理由により、私はそれらのPRを受け入れません。
- 変更点の多くはより良いものですが、一部はコードに何らかの影響を及ぼし、通常はパフォーマンスに影響を与えます。良い部分を適切に選択するのは大変な作業です。
- すべての変更が無害または有益であったとしても、すべてのコミットのすべてのファイルのすべての変更を確認する必要があり、繰り返しになりますが、時間がかかりすぎます。
とはいえ、誰かがより良いエラーチェックやドキュメントコメントを追加したい場合は、そのPRをハートビートで受け入れます。
それらは小さく、簡単に修正できますが、攻撃を修正してプルリクエストを作成することにより、オープンソースプロジェクトのコーディングスタイルを変更してもよいと思いますか？
つまり、いいえ！
もちろん、ここではこれらはスタイルの問題であり、実際のバグではないと想定しています。後者のプルリクエストは常に賢明です（IMO）。また、あなたがプロジェクトに慣れていないことを想定しています。すでにそれを維持している人々とは接触していません。
ただし、どの言語でも、良いか悪いかはスタイルガイドとは異なる好みがあり、そのスタイルの変更を知らないの人に強制しようとする人が常にいます。 あなたはその一部ではありませんをプロジェクトします。結局のところ、リクエストが受け入れられた場合、実際には何を達成していますか？おそらく、あるプロジェクトのメンバーがスタイルを別のスタイルに変更したい場合、彼らはすでにそれを実行しているでしょう-そして、あなたがそのリクエストで行うすべてのことは、必ずしもうまく機能しないスタイルを強制することです既存のメンバーのために。
スタイルの「修正」以外の方法でプロジェクトに貢献したい場合、これは少し変更されます。プロジェクトにどのように取り組みたいかについてメンテナとの対話を開きたいが、非標準的なスタイルが難しいと感じたら、それで結構です。しかし、スタイルの変更のみを含む多数のプロジェクトのプルリクエストを盲目的に作成するだけではありません。
いかなる変更も、コードの表記上の書式を変更する場合でさえも、バグを引き起こす可能性があります。
したがって、有効なビジネスケースがない限り、コードに変更を加える必要はありません。「コードは見栄えがよくない」または「コードがコーディング基準に従っていない」は、有効なビジネスケースではありません。 。リスクが大きすぎるだけです。
さて、とにかくソースファイルに大きな変更を加える場合は、標準に沿ってファイル全体をプルすることは受け入れられるかもしれませんが、ほとんどの場合、小さな変更を加えることになります。既存のコードがコーディング標準に従っていない場合でも、既存のコードに合わせて独自の変更を維持してください。
つまり、コードはコードジェネレーターの結果である可能性があり、場合によっては再生成されます。コードジェネレーターは、醜いコードを生成することで有名です...