オープンソースのエチケット

Codeplexでの最初のオープンソースプロジェクトの作業を開始し、いくつかのひどいコードに遭遇しました。（C＃にはまだ「goto」ステートメントがあることを学びました）「所有者」が望んでいた機能を追加し始め、コードベースを調べて、それが何であるかを確認しました（例：「goto」を使用）少し。しかし、私は少し心配しているので、私はあなたにすべてを向けている理由です：私にとって「悪いコード」を「修正」するのは適切なエチケットですか、それをそのままにして新しい機能に取り組むべきですか？前にも言ったように、私はOSSシーン全体に不慣れであり、チーム全体で作業しているので、混乱しないようにしたいと思います。

あなたがそれについて控えめで、それが何も壊さない場合、これを行うことは問題ありません。コードを再フォーマットしてバグを導入することはできません。優れた単体テストがありますか？そうでない場合は、ユニットテストを追加して貢献を開始し、後で構造を修正します。

オープンソースの目的は、プロジェクトにもっと目を向け、それを改善することです。それにはコードの改善も含まれます。そうは言っても、あなたが何をするつもりなのかをリストに広告するのは良い形です。プッシュバックされる場合もあれば、たくさんの+1が返される場合もあります。goto原作者は仕事を成し遂げるためのより良い方法を考えることができなかったので、それらの声明はそこにあるかもしれません。プッシュバックが発生した場合は、ダイアログを入力して、どこから圧力がかかっているのかを確認することをお勧めします。それが個人的なものにならないようにし、懸念に対処するようにしてください。

要するに、単体テストはドグマよりも雄弁です。特定のケースで現在のようにコードが誤動作することを証明できる場合は、親指を立てるか、元の作者が介入して問題を修正します。

オープンソースでは、コミュニティはコードよりも重要です。コミュニティがない場合（ユーザーと開発者の両方）、プロジェクトはありません。

通常、コードについてabout心を込めて守っている人は、それを世界中に精査するために投稿しません。気をつけてください。しかし、感情を傷つけることを心配しないでください。

時間をかけすぎないうちに、やりたいことを伝えてください。時々、非自明なことの歴史的な理由があります。gotosが回避される理由は、コードを介して予期しないパスが生成される可能性があるためです。したがって、gotoを削除する危険性は、有益なパスの1つに気付かず、リファクタリングから誤って削除してしまうことです。

一方、元の作者は、その時点でそれをよりきれいに書く方法を考えられなかったかもしれません。これは、コードが言葉よりも大声で話す場所です。私が最初にオープンソースに貢献したことの1つは、パフォーマンスを大幅に向上させる取り消しスタックの修正でしたが、一部のコア開発者は、最初に説明したときに複雑すぎると言っていました。短いコードサンプルにより、それらがボードに搭載されました。

そのままにしておく正当な理由があることが判明した場合、少なくともそれらの理由を説明するコメントを求めます。

経験から言えば...

私が貢献した最初のオープンソースプロジェクトは、私も最初に始めたとき、私はすべて小便と酢でいっぱいでした。

私がすぐにやったのは、たくさんのソースファイルを調べて、自分の好みに合わせてスタイルを整え、大規模なパッチを作成し、それを提出したことです。

「私がそうだったように」「良い」人と作業している場合は、すぐにパッチを拒否します。主に、あなたがオープンソースプロジェクトに貢献するとき、単一の問題に対処する一口サイズのチャンクに修正を分解することが期待されるからです。「すべてのgotosを削除」は、アトミックコミットの良い例ではありません。最初に小さく、よく文書化されたコミットに分割しても、拒否される可能性があります。

その理由は、コードは時間の経過とともに複数の人（スタイルの異なる）によって処理されるため、ある開発者のスタイルに合わせてライブラリ全体の変更を受け入れることは実際には実行不可能だからです。スタイルのためにスタイルを変更することが実現可能であれば、すべてのオープンソースプロジェクトが前進することはありません。コードはさまざまな開発者スタイルに合わせて絶えず編集されるためです。

コードのリファクタリングと機能の追加（または廃止された不要なデータの削除）は、通常、「クリーニング」コードよりも優先されます。

オープンソースプロジェクトでの作業の中で最も難しく、最もやりがいのある部分は、あなたが提出している変更を行うことを提案する理由を尋ねられることです。正当な理由を説明できれば、パッチが提出される可能性が高くなります。

私のアドバイスは、これらの変更のいくつかを1つのソースファイルで実行して、最初にやろうとしていることを味わうことです。変更が十分に正当化され受け入れられている場合は、そのような変更がプロジェクトの品質を改善するかどうかを尋ねます。そうすれば、将来パッチが拒否されても、何もせずに多くの労力を無駄にすることはありません。

オープンソースの開発は、コードを書くだけではありません。ゲートキーパー（プッシュアクセスを制御する開発者）がプロジェクトの整合性を保護するために必要なことを行うため、信頼関係の構築に取り組んでいます。より多くのパッチを提出すると、ゲートキーパーはあなたのスタイルをより良く感じるようになり、変更をそれほど正当化する必要がなくなります。

それには時間がかかるプロセスですが、とてもやりがいがあります。あなたは他の誰かのコードを見て、批判することから多くを学ぶだけでなく、あなた自身のスタイルについて批評されるでしょう。

「他のコーディングスタイルのエラーの不正を修正する」ために多くの時間を無駄にする前に、次のことを自問してください。

あなたが提案している変更は、プロジェクトへの付加価値に基づいているのですか、それともあなた自身の内部のスタイルの宗教に基づいているのですか。

Stack Overflow（および関連するStack Exchangeサイト）には多くの宗教があります。私は多くのことを意味します。人々はスタイルについて無限に考え、話します。まるでそれについて話すほど、「完璧で、理想的で、破壊不可能で、間違いのない」コーディングスタイルに近づきます。それは楽しいからだ。

オープンソースの世界では、スタイルはそれほど重要ではありません。機能はです。

注：このアドバイスはすべて、ゲートキーパーが合理的で才能のあるプログラマーであることを前提としています。もしそうなら、幸運なことに、あなたの唯一の関心事が彼らの「赤ちゃん」を保護している気まぐれなb @＆＃＆esの1つで立ち往生しなかったことを幸運に思ってください。それらは自然界に存在するので、遭遇しても驚かないでください。

品質>エチケット

私の意見では、品質が悪いことに気づいたらすぐに他の人のコードを編集することを心配しないでください。優れたソフトウェア品質を実現するには、単純にコードをきれいにする必要があります。他の人のコードの改善をコミットしても問題はありません。他の人は、自分のコードに取り組んでいるコーダーがいることを認識し、感謝すべきです。

「goto」を使用せずに問題を解決するためのより良い方法を見つけることができるなら、私はそれのために行くことをお勧めします。今日のコードを改善するための少しの努力は、将来的にあなたがより多くの努力を節約するかもしれません。

原作者とコミュニケーションを取ることも良い考えです。

暗黙的に間違っているものは何もありませんgoto。アセンブリコードを見てください-いたるところにたくさんのgoto（ジャンプとブランチ）があります。

理由gotoこのごろ悪い名前を持っているがためにダイクストラ紙であり、有害とみなさGO TO文に非常に悪いとgoto文を正確に指摘しました。

ソフトウェアエンジニアリングの名前がまだ付けられていない50年前のことであり、ほとんどのプログラミング言語は基本的に機械語の抽象化であり、機械語にはgotoが含まれていました。Microsoft Basic（Appleのオリジナルの[] [またはCommodore 64）でプログラミングを試して、その考え方がどのようなものかを理解してください。

ダイクストラが主張していたのは、物事をシンプルに保つために、あちこちに飛び回るのではなく、共通のエンディングでよりシンプルなプログラムパスを保つことでした。たとえば、メソッドからの戻り。言い換えれば、グローバルジャンプではなく、ローカルジャンプのみです。

これは、引数を使用したメソッド呼び出し、コードのモジュール化、パッケージなど、ソフトウェア開発の複雑さを抑えるために導入されたものなどを取り入れるためのステップでした。gotoステートメントは、その戦争の最初の傍観者に過ぎませんでした。