貢献ガイドライン
貢献者の皆様へ
微積分の数値計算に関連するさまざまな科学計算ライブラリに詳しい開発者の皆様の参加、コードの貢献、そして貴重な経験の共有を心より歓迎します。同時に、初心者の方には開発やドキュメントの改善に参加しながら、微積分に関する数値計算手法を学び身につけることをお勧めします。経験豊富な開発者も初心者も、プロジェクトのドキュメント、表、コード例を通じて、興味のある貢献目標を見つけられることを願っています。
本プロジェクトに貢献してくださったすべての開発者の皆様に心より感謝申し上げます。コードの提出、ドキュメントの改善、貴重なフィードバックなど、皆様一人ひとりの努力がこのプロジェクトをより良いものにしています。開発における皆様の熱意と知恵がプロジェクトを前進させ続け、コミュニティに新たな協力の機会をもたらしています。皆様のご支援と献身に感謝するとともに、共にさらなる成果を上げ、このプロジェクトをより明るい未来へと導いていけることを楽しみにしています。
1. コードスタイル
-
本プロジェクトは MoonBit ツールチェインが採用するフォーマット規則に従う。以下のコマンドを実行してコードを自動でフォーマットすること。
moon fmtコードの一貫性を保つために、コミット前に
moon fmtを実行すること。また、
ready_to_pr.shスクリプトを実行してコードのフォーマット、チェック、テストカバレッジファイルの生成、.mbtiファイルの生成を行うことも可能。
2. 名前の命名規則
2.1 変数の命名
- 小文字とアンダースコア(
_)を使用(例:my_var)。 - 変数名は意味が明確で、用途が直感的に理解できるものにする。
2.2 関数の命名
- 小文字とアンダースコア(
_)を使用(例:calc_total_price())。 - 関数名は簡潔かつ説明的にし、機能が明確に分かるようにする。
2.3 ストラクトとトレイトの命名
- パスカルケース(PascalCase)を使用(例:
MyStruct,MyTrait)。 - 機能や役割を直感的に表す名前を使用し、抽象的すぎる名前は避ける。
2.4 定数の命名
- 注意: MoonBit では「変数」は通常「束縛(binding)」と呼ばれ、
mutを付けない限り既定で不変です。そのため、定数と変数の命名に厳密な区別はありません。 - 小文字とアンダースコア(
_)を使用(例:machine_dbl_epsilon)。 - 必要に応じてカテゴリーをプレフィックスとして付与(例:
machine_dbl_epsilonは機械関連の定数)。 - 分かりやすく、簡潔な名前を付ける。
2.5 結果エラーのエラーコードの設計
- 大文字とアンダースコア(
_)を使用(例:E_MAX_ITER)。 - エラーコードには
Eをプレフィックスとして付与。 - 短く分かりやすいエラーコードを心掛ける。
3. コメント
- 簡潔さ:冗長にならず、明確に記述する。
- 一貫性:コード全体で統一された用語とスタイルを使用する。
- 明確さ:分かりやすい表現を用い、曖昧な表現や専門用語の多用を避ける。
- 正確さ:コードの動作や目的を正しく反映する。
- 最新状態の維持:コードの変更に応じてコメントを更新する。
開発者は MoonBit LSP の AI によるコードコメント生成機能を活用できるが、AI が生成したコメントは必ずレビューし、正確性を確認すること。
4. ファイルの規格
4.1 フォルダ名の命名
-
小文字のみを使用。
-
フォルダ名は簡潔で内容がわかるものにし、単語はアンダースコア(
_)で区切ってください。数字や特殊文字は避けてください。例:
- 微分関連の機能:
diff - 導関数関連の機能:
deriv
- 微分関連の機能:
4.2 ファイルの構成
-
ファイルは機能ごとに整理し、それぞれ特定の機能に焦点を当てる。ファイル名には小文字とアンダースコアを使用する。
-
ファイル名は説明的にし、実装している中心的な機能を明確に示すものにする。
例:
gauss_kronrod.mbt: ガウス求積法(クロンスロッド拡張)を実装。adaptive_quadrature_gk.mbt: ガウス求積法(クロンスロッド拡張)を用いた適応型求積法を実装。
-
注意:
utils.mbtのような汎用的すぎる名前は避け、機能を明確に表す名前を使用すること。
5. コミット規則
5.1 コミットメッセージ
-
ready_to_pr.shスクリプトを実行し、コードフォーマット、チェック、テストカバレッジ生成、.mbtiファイル生成を行うこと。 -
コミットごとに変更内容を明確に記述する。
-
コミットメッセージは英語で、簡潔かつ明確に記述する。
-
fix:,feat:,refactor:,doc:などのプレフィックスを使用。例:
fix: fix bug in something feat: add feature for something refactor: refactor something doc: add docs for something
5.2 コミットの頻度
- コミットは小さく、一つの機能や修正に集中させる。
- 複数の変更を一つの大きなコミットにまとめないこと。
6. コードレビュー
moon.mod.jsonの依存関係やバージョンを変更する前に、メンテナーまたはコラボレーターに確認すること。- すべてのコードはコードレビューを受ける必要がある。
- コードレビューでは、コードの品質、スタイル、パフォーマンス、セキュリティを重視する。
- レビュアーは建設的なフィードバックを提供し、コードの改善に努める。