オープンソースのエチケット
私はCodeplexで最初のオープンソースプロジェクトに取り組み始め、ひどいコードに出くわしました。 （私はC＃にまだ「goto」ステートメントがあることを知っていました）「所有者」が望む機能を追加し始め、コードベースを調べて混乱を確認した後（たとえば、「goto」を使用して）クリーンアップしたいと思いました少し。しかし、私は少し心配しています。それが私が皆さんに目を向けている理由です。「悪いコード」を「修正」するのが適切なエチケットですか、それともそれを修正して新しい機能に取り組むべきですか？前に言ったように、私はOSSシーン全体に不慣れで、一般的にチームで作業しているので、それを台無しにしたくありません。
あなたがそれについて謙虚で、それが何も壊さないなら、これを行うのは問題ありません。コードの再フォーマットやバグの導入を回避することはできません。良い単体テストはありますか？そうでない場合は、単体テストを追加することから始めて、後で構造を修正します。
オープンソースの目的は、プロジェクトにもっと目を向け、それを改善することです。これには、コードの改善も含まれます。そうは言っても、あなたが何をしようとしているのかをリストに載せることは良い形です。プッシュバックを受けることもあれば、+ 1の束を受け取ることもあります。これらのgotoステートメントは、元の作者が仕事を成し遂げるためのより良い方法を考えることができなかったために存在する可能性があります。プッシュバックを受け取った場合は、ダイアログを入力して、圧力がどこから来ているのかを確認することをお勧めします。それが個人的にならないようにして、懸念事項に対処してください。
結論として、単体テストはドグマよりも雄弁です。特定の場合に現在のようにコードが誤動作することを証明できれば、親指を立てるか、元の作者が問題を修正するでしょう。
オープンソースでは、コミュニティはコードよりも重要です。コミュニティ（ユーザーと開発者の両方）がない場合、プロジェクトはありません。
コードに嫉妬している人々は一般に、世界を精査するためにそのコードを投稿しません。もしそうしたとしても、その周りのコミュニティはそれほど長くは続きません。機知に富んでいても、気持ちを傷つけることを恐れないでください。
時間をかけすぎる前に、何をしたいかを伝えてください。時には、自明ではないものに歴史的な理由があります。 gotosが回避される理由は、コードを通じて予期しないパスを生成する可能性があるためです。したがって、gotosを削除する危険性は、有益なパスの1つに気付かず、誤ってリファクタリングから除外することです。
一方、おそらく、元の作者はその時点でそれを書くためのより明確な方法を考えられなかっただけかもしれません。これは、コードが言葉よりも大きな声で話す場所です。彼らがあなたがそれらを示すまで、それがよりきれいにできると彼らは信じないかもしれないからです。私の最初のオープンソース貢献の1つは、パフォーマンスを大幅に改善するundoスタックの修正でしたが、コア開発者の一部は、最初にそれを説明したときに複雑すぎるように聞こえたと言いました。短いコードサンプルがそれらを実装しました。
そのままにしておくのに十分な理由があることがわかった場合は、少なくともそれらの理由を説明するコメントをプッシュします。
経験から言えば...
私が最初に貢献したオープンソースプロジェクトは、私も最初に始めたときは全員小便と酢でいっぱいでした。
私がすぐにしたことは、たくさんのソースファイルを調べて、個人的な好みに合わせてスタイルを整え、大規模なパッチを作成して送信することでした。
「私」のように「良い」人と一緒に作業している場合、彼はすぐにパッチを拒否します。主な理由は、オープンソースプロジェクトに貢献するとき、修正を1つの問題に対処する一口サイズのチャンクに分解することが期待されるためです。 「すべてのgotosを削除する」は、アトミックコミットの良い例ではありません。それを小さく、十分に文書化されたコミットに最初に分解しても、それでも拒否される可能性があります。
その理由は、コードは時間の経過とともに（スタイルの異なる）複数の人が作業するため、1つの開発者のスタイルに合わせてライブラリ全体の変更を受け入れることは実際には実現不可能だからです。スタイルのためにスタイルを変更することが可能である場合、コードはさまざまな開発者のスタイルに合わせて常に編集されるため、すべてのオープンソースプロジェクトが前進することはありません。
コードのリファクタリングと機能の追加（または非推奨の残骸の削除）は、通常、「クリーニング」コードよりも優先されます。
オープンソースプロジェクトでの作業で最も困難でやりがいのある部分は、次のように尋ねられます理由送信する変更を加えることを提案しています。正当な理由がある場合は、パッチが送信される可能性が高くなります。
私のアドバイスは、これらの変更のいくつかを1つのソースファイルで実行して、最初に実行しようとしていることを味わうことです。変更が十分に正当化されて受け入れられている場合は、プロジェクトの品質を向上させるような変更がさらにあるかどうかを尋ねます。そうすれば、将来パッチが拒否されても、無駄な労力を費やすことはありません。
オープンソースの開発は、コードを書くだけではありません。ゲートキーパー（プッシュアクセスを制御する開発者）willがプロジェクトの整合性を保護するために必要なことを行うため、信頼関係を構築するために作業しています。より多くのパッチを提出すると、ゲートキーパーはあなたのスタイルをよりよく感じるようになり、変更をそれほど正当化する必要がなくなります。
時間のかかるプロセスですが、やりがいがあります。見たり、他人のコードを批評したりすることから多くを学ぶだけでなく、あなた自身のスタイルで批評されますwill。
「他人のコーディングスタイルのエラーの不正を修正する」ために多くの時間を無駄にする前に、次のことを自問してください。
あなたが提案している変更は、プロジェクトへの付加価値に基づいていますか、それともあなた自身の内部の文体的宗教に基づいています。
Stack Overflow（および関連するStack Exchangeサイト）にはlotの信仰があります。つまりlotです。人々はスタイルについて無限に考え、話します。まるでそれについて話すほど、「完璧で理想的で、破壊されず、間違いのない」コーディングスタイルに近づくようです。おもしろいので、話をしすぎます。
オープンソースの世界では、スタイルはそれほど重要ではありません。関数is。
注：このアドバイスはすべて、ゲートキーパーが合理的で才能のあるプログラマであることを前提としています。もし彼がそうであるなら、あなたの唯一の関心が彼らの「赤ちゃん」を保護している気まぐれなb @＆＃＆esの1つに行き詰まらなかったことを幸運とみなしてください。彼らはdoが実在しているので、遭遇しても驚かないでください。
品質>エチケット
私の意見では、他の人のコードの品質が悪いことがわかってもすぐに編集することを心配するべきではありません。優れたソフトウェア品質を実現するには、単純にクリーンなコードを気にする必要があります。他の人のコードの改善をコミットすることに問題はないと思います。他の人が自分のコードに取り組んでいるプログラマーがいることを認識し、感謝すべきです。
gotoに暗黙的に問題はありません。アセンブリコードを見てください-あちこちにたくさんのgoto（ジャンプとブランチ）があります。
最近のgotoの名前が悪いのは、ダイクストラの論文 Go Toステートメントが有害と見なされている がgotoステートメントを非常に悪いものとして特定したためです。
これは50年前のことであり、ソフトウェアエンジニアリングはまだ名前が付けられていませんでした。ほとんどのプログラミング言語は、基本的には基本となるマシンの抽象化であり、機械語にgotoが含まれていたためです。 Microsoft Basic（Apple] [またはCommodore 64）の元のプログラム）でプログラミングしてみて、その考え方がどのようになっていたかを知ることができます。
ダイクストラが主張していたのは、物事をシンプルに保つために、あちこちにジャンプするのではなく、共通のエンディングを持つシンプルなプログラムパスを維持することでした。例えば。メソッドからの戻り。つまり、グローバルジャンプではなく、ローカルジャンプのみです。
これは、引数付きのメソッド呼び出し、コードのモジュール化、パッケージなどを導入するためのステップでした。これらはすべて、ソフトウェア開発の複雑さを緩和するために導入されました。 gotoステートメントは、その戦争の最初の傍観者にすぎませんでした。
「goto」を使用せずに問題を解決するためのより良い方法を見つけることができるなら、私はそれのために行くことをお勧めします。今日のコードを改善するための少しの努力は、将来的にあなたに多くの努力を節約するかもしれません。
元の作者と連絡を取ることも良い考えです。