Code Review Notes#

このドキュメントには、pgAdminに含めるように送信された変更のレビュープロセス中にチェックされる多数の標準項目がリストされています。

すべてのコードがpgAdmin Coding Standards に従っていることを確認します。
すべてのコードに単体テストカバレッジとAPI/機能テストカバレッジが必要に応じてあることを確認します。
著作権年は正しく、適切にフォーマットされている必要があります毎年大量の更新を簡単に行うことができます。開始日は常に2013年であり、終了年は現在の年である必要があります。例

Copyright (C) 2013 - 2025、pgAdmin開発チーム
著作権ヘッダーの直後に空白行があることを確認します。
ファンクション、クラス、モジュールのPyDocコメントを含めます。ノードモジュールは/"/"/"Implements the XXXX node/"/"/"である必要があります。
生成されたSQLに先頭または末尾の空白行がなく、適切なフォーマットのために一貫して4つのスペースインデントを使用していることを確認します。
Slonyオブジェクトを特殊ケースにしないでください。 pgAdmin 3とは異なり、pgAdmin 4にはSlonyの直接の知識がありません。
モジュールをコピー/ペーストする場合は、コメントが適切に更新されていることを確認してください。
すべてのコメントを読み、それらが意味をなしていることを確認し、コードに役立つコメントを提供します。
フィールドラベルは両方ともPostgreSQL用語を使用しているが、説明的なものであることを確認します。良い例は、FTSテンプレートの/"Init/"フィールドです。
可能な場合はコードを再利用しますが、適切な中央の場所に分解します。変更が必要な場合を除き、コピー＆ペーストしないでください。
コードを読みやすいように適切にフォーマットします。コードの論理チャンクを空白行で分割し、コメントしてコードのさまざまなセクションが何用または関連しているかを説明します。
フォーム検証が正しく動作し、エラーの表示方法が他のダイアログと一貫していることを確認します。
SchemaまたはOwnerフィールドを使用したダイアログでは、必要に応じてデフォルト値を現在のスキーマ/ユーザーに事前設定します。一般に、使用可能な一般的なまたは合理的なデフォルト値がある場合は、ユーザーのフィールドにそれらを入力します。
1プルリクエスト == 1機能。変更で既存のインフラストラクチャを修正/更新する必要がある場合、通常は別のプルリクエストであると簡単です。複数の新機能または無関係な変更を含むプルリクエストは拒否される可能性があります。
変更が完全に機能し、動作することを確認します。コミットを目的としないWIP変更を送信する場合は、プル要求を送信する代わりに、リポジトリフォークへのリンクまたはパッチとしてpgadmin-hackers@postgresql.orgメーリングリストに送信します、それがWIPであることを明確に示し、何がまだ機能するか、していないかに注目してください。