Code Review Notes¶
このドキュメントには、pgAdminに含めるために送信された変更のレビュープロセス中にチェックされる多くの標準項目がリストされています。
すべてのコードがpgAdmin Coding Standards に従っていることを確認します。
すべてのコードに、必要に応じて単体テストのカバレッジとAPI/機能テストのカバレッジがあることを確認します。
著作権の年は、正確で適切な形式である必要があります（毎年の一括更新を簡単にするため）。開始日は常に2013年、終了年は現在の年にする必要があります。
Copyright(C)2013-2023、pgAdmin開発チーム
著作権ヘッダーの直後に空白行があることを確認します。
関数、クラス、モジュールのPyDocコメントを含めます。ノードモジュールは/"/"/"XXXXノードを実装します/"/"/"
生成されたSQLには、先頭または末尾に空白行がなく、適切なフォーマットのために4つのスペースインデントが一貫して使用されていることを確認します。
Slonyオブジェクトを特別なケースにしないでください。pgAdmin3とは異なり、pgAdmin4はSlonyを直接認識しません。
モジュールをコピーして貼り付ける場合は、コメントが適切に更新されていることを確認してください。
すべてのコメントを読んで、それらが理にかなっていることを確認し、コードに役立つコメントを提供します。
フィールドラベルは両方ともPostgreSQLの用語を使用するだけでなく、説明的であることを確認します。良い例は、FTSテンプレートの/"Init/"フィールドです。InitはPG用語ですが、その後に単語/"Function/"を追加すると、はるかに説明的になります。
可能な限りコードを再利用しますが、適切に中央の場所に分解します。変更が必要な場合を除き、コピーして貼り付けないでください。
コードを読みやすいようにフォーマットします。コードの論理的なチャンクを空白行で分割し、適切にコメントして、コードのさまざまなセクションが何を対象としているかを説明します。
フォームの検証が正しく機能し、エラーの表示方法が他のダイアログと一貫していることを確認します。
スキーマまたは所有者フィールドを使用したダイアログで、必要に応じてデフォルト値を現在のスキーマ/ユーザーに事前設定します。一般に、一般的なまたは適切なデフォルト値がある場合は、それらをユーザーのフィールドに入力します。
1つのプルリクエスト==1つの機能。変更で既存のインフラストラクチャを修正/更新する必要がある場合、通常は別のプルリクエストにある方が簡単です。複数の新機能または無関係な変更を含むプルリクエストは拒否される可能性があります。
変更が完全に機能し、動作することを確認します。コミットを意図していない進行中の（WIP）変更を送信したい場合は、プルリクエストを送信する代わりに、リポジトリフォークへのリンクまたはパッチとしてpgadmin-hackers@postgresql.orgメーリングリストに送信します、それがWIPであることを明確に述べ、まだ機能していないことを指摘します。
