貢献ガイドライン

コードスタイル

• 本プロジェクトは MoonBit ツールチェインが採用するフォーマット規則に従う。以下のコマンドを実行してコードを自動でフォーマットすること。

  moon fmt

  コードの一貫性を保つために、コミット前に moon fmt を実行すること。

  また、ready_to_pr.sh スクリプトを実行してコードのフォーマット、チェック、テストカバレッジファイルの生成、.mbti ファイルの生成を行うことも可能。

名前の命名規則

変数の命名

• 小文字とアンダースコア（ _ ）を使用（例: my_var）。
• 変数名は意味が明確で、用途が直感的に理解できるものにする。

関数の命名

• 小文字とアンダースコア（ _ ）を使用（例: calc_total_price()）。
• 関数名は簡潔かつ説明的にし、機能が明確に分かるようにする。

ストラクトとトレイトの命名

• パスカルケース（PascalCase）を使用（例: MyStruct, MyTrait）。
• 機能や役割を直感的に表す名前を使用し、抽象的すぎる名前は避ける。

定数の命名

• 注意： MoonBit では「変数」は通常「binding」と呼ばれ、mut を付けない限り既定で不変です。そのため、定数と変数の命名に厳密な区別はありません。
• 小文字とアンダースコア（ _ ）を使用（例: machine_dbl_epsilon）。
• 必要に応じてカテゴリーをプレフィックスとして付与（例: machine_dbl_epsilon は機械関連の定数）。
• 分かりやすく、簡潔な名前を付ける。

結果エラーのエラーコードの設計

• 大文字とアンダースコア（ _ ）を使用（例: E_MAX_ITER）。
• エラーコードには E をプレフィックスとして付与。
• 短く分かりやすいエラーコードを心掛ける。

コメント

• 簡潔さ：冗長にならず、明確に記述する。
• 一貫性：コード全体で統一された用語とスタイルを使用する。
• 明確さ：分かりやすい表現を用い、曖昧な表現や専門用語の多用を避ける。
• 正確さ：コードの動作や目的を正しく反映する。
• 最新状態の維持：コードの変更に応じてコメントを更新する。

開発者は MoonBit LSP の AI によるコードコメント生成機能を活用できるが、AI が生成したコメントは必ずレビューし、正確性を確認すること。

ファイルの規格

フォルダ名の命名

• 小文字のみを使用。
• フォルダ名は簡潔かつ説明的にし、アンダースコア（ _ ）で区切る。数字や特殊文字は避ける。例えば、微分関連の機能には diff、導関数関連の機能には deriv を使う。

ファイルの構成

• ファイルは機能ごとに整理し、それぞれ特定の機能に焦点を当てる。ファイル名には小文字とアンダースコアを使用する。
• ファイル名は、実装する中心的な機能が明確に分かるものにする。例えば、gauss_kronrod.mbt はガウス・クロンロッド求積法を、adaptive_quadrature_gk.mbt はガウス・クロンロッド求積法による適応型求積法を実装する。
• 注意：utils.mbt のような汎用的すぎる名前は避け、機能を明確に表す名前を使用すること。

コミット規則

コミットメッセージ

• 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

コミットの頻度

• コミットは小さく、一つの機能や修正に集中させる。
• 複数の変更を一つの大きなコミットにまとめないこと。

コードレビュー

• moon.mod.json の依存関係やバージョンを変更する前に、メンテナーまたはコラボレーターに確認すること。
• すべてのコードはコードレビューを受ける必要がある。
• コードレビューでは、コードの品質、スタイル、パフォーマンス、セキュリティを重視する。
• レビュアーは建設的なフィードバックを提供し、コードの改善に努める。