貢献ガイド

はじむプロジェクトへの貢献を歓迎します！このガイドでは、プロジェクトに貢献する方法を説明します。

貢献の種類

開発環境のセットアップ

1. リポジトリのフォーク

GitHubでリポジトリをフォークします。

2. クローン

git clone https://github.com/あなたのユーザー名/jp.git
cd jp

3. ビルド

make clean
make

4. テストの実行

# すべてのテストを実行
./nihongo test_all.jp

# 特定のテストを実行
./nihongo tests/stdlib.jp

5. 開発ブランチの作成

git checkout -b 機能名-または-修正内容

コード貢献のプロセス

ステップ1: Issue を作成または選択

• 新機能やバグ修正の前に、GitHub Issuesで確認
• 既存のIssueがなければ新規作成
• 作業を開始する前にコメントで意思表示

ステップ2: コードを書く

• 既存のコードスタイルに従う
• コメントは日本語または英語で記述
• 小さく頻繁にコミット
• 意味のあるコミットメッセージを書く

コミットメッセージの規約

# 形式
<type>: <subject>

# 例
feat: リスト内包表記を実装
fix: 配列の境界チェックを修正
docs: チュートリアルに非同期処理の説明を追加
test: 文字列操作のテストケースを追加
refactor: パーサのコードを整理

Type の種類:

• feat: 新機能
• fix: バグ修正
• docs: ドキュメントのみの変更
• test: テストの追加や修正
• refactor: リファクタリング
• perf: パフォーマンス改善
• chore: ビルドプロセスやツールの変更

ステップ3: テストを追加

• 新機能には必ずテストを追加
• バグ修正には再現テストを追加
• 既存のテストが壊れていないか確認

ステップ4: プルリクエストを作成

# 変更をプッシュ
git push origin ブランチ名

• GitHubでプルリクエストを作成
• 変更内容を明確に説明
• 関連するIssue番号を記載（例: Closes #123）
• スクリーンショットや動作例を添付（該当する場合）

ステップ5: レビューと修正

• メンテナーからのフィードバックに対応
• CIテストがパスすることを確認
• 必要に応じて修正をコミット

コーディングガイドライン

C言語コード（インタープリタ本体）

• インデント: スペース4つ
• 関数名: スネークケース（例: evaluate_expression）
• 変数名: スネークケース
• 定数: 大文字スネークケース（例: MAX_STACK_SIZE）
• ポインタ: 型の後ろにアスタリスク（例: char* str）
• メモリ管理: 必ずfree()を対応させる
• エラーチェック: NULLチェックを忘れない

// 良い例
Value* evaluate_expression(ASTNode* node, Environment* env) {
    if (node == NULL || env == NULL) {
        return NULL;
    }
    
    // 処理...
    
    return result;
}

はじむコード（サンプルやテスト）

• インデント: スペース4つ
• 変数名: 日本語の名詞（例: 合計、ユーザー名）
• 関数名: 日本語の動詞（例: 計算する、検証）
• わかりやすいコメントを書く

// 良い例
関数 合計計算(配列):
    変数 合計 = 0
    各 数値 を 配列 から
        合計 = 合計 + 数値
    終わり
    戻す 合計
終わり

テストガイドライン

テストファイルの配置

• tests/: 言語機能のテスト
• examples/: サンプルコード（動作確認も兼ねる）

テストの書き方

// tests/new_feature_test.jp

// テスト: 新機能の基本動作
変数 結果 = 新機能(10, 20)
もし 結果 != 30 なら
    表示("エラー: 期待値は30だが", 結果, "が返された")
終わり

// テスト: エッジケース
変数 空結果 = 新機能(0, 0)
もし 空結果 != 0 なら
    表示("エラー: ゼロケースが失敗")
終わり

表示("✓ すべてのテストが成功")

テストのベストプラクティス

• 1つの機能につき複数のテストケース
• 正常系と異常系の両方をテスト
• エッジケースを忘れない（空配列、ゼロ、NULL等）
• テストは独立して実行可能に
• わかりやすいエラーメッセージ

ドキュメント貢献

ドキュメントの種類

• README.md: プロジェクト概要
• docs/TUTORIAL.md: チュートリアル
• docs/REFERENCE.md: 言語リファレンス
• docs/ROADMAP.md: 開発計画
• jp-document/: 公式ウェブサイト

ドキュメント改善のアイデア

• 誤字脱字の修正
• 不明瞭な説明の改善
• コード例の追加
• 図やダイアグラムの追加
• よくある質問の追加
• トラブルシューティング情報

バグ報告の方法

良いバグ報告には以下が含まれます：

1. 明確なタイトル

例: 「配列の境界外アクセスでクラッシュ」

2. 環境情報

• OS（macOS 14.0、Ubuntu 22.04等）
• コンパイラ（GCC 11.4、Clang 14.0等）
• 言語のバージョン（コミットハッシュまたはリリースバージョン）

3. 再現手順

1. 以下のコードを test.jp として保存
2. ./nihongo test.jp を実行
3. エラーが発生

4. 再現コード

// 最小限の再現コード
変数 配列 = [1, 2, 3]
表示(配列[10])  // ここでクラッシュ

5. 期待される動作

「エラーメッセージが表示されるべき」

6. 実際の動作

「セグメンテーションフォルトで終了」

7. エラーメッセージ（あれば）

Segmentation fault: 11

機能提案の方法

良い機能提案には以下が含まれます：

1. 問題の説明

「現在、並列処理のサポートがないため、複数のHTTPリクエストを同時に処理できない」

2. 提案する解決策

「スレッドプールまたは軽量なコルーチンを実装する」

3. 使用例

// 提案する構文
並列
    タスク1()
    タスク2()
    タスク3()
待つ  // すべてのタスクが完了するまで待機

4. 代替案（あれば）

「async/awaitの拡張でも実現可能」

5. 影響範囲

「既存のコードに影響なし、新しい構文の追加のみ」

コミュニティガイドライン

行動規範

• 敬意を持つ: すべての貢献者を尊重する
• 建設的に: 批判は建設的に、解決策を提示
• 協力的に: 他の人を助け、知識を共有
• 忍耐強く: 初心者にも親切に
• オープンに: フィードバックを受け入れる

コミュニケーション

• 日本語または英語でコミュニケーション
• 丁寧な言葉遣いを心がける
• 明確で簡潔に伝える
• 絵文字やフォーマットを活用して読みやすく

よくある質問