CODING_GUIDELINE.md

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

[Scala] nullを使わない

Scalaのファイルにおいては、nullを使用する代わりにOptionを使用してください。

Java (特に、Bukkit/Spigot API) から入ってきた値がnullになる可能性がある場合は、その呼び出しを早いうちにOption(...)で囲い、Optionにすることが推奨されます。この呼び出しで、引数がnullだった場合はNoneに、そうでなかった場合はSome(...)になります。

[Scala] 例外を使わない

例外の代わりにEitherを使用してください。Eitherを使用すると低コストで合成を行うことができるためです。

Javaコードを追加しない

Scalaを書くことができる場合はScalaを使ってください。

メインスレッドでの処理は最小限に

メインスレッドで計算なども含めたすべての処理を行うことはサーバーのラグにつながるため、推奨されません。 推奨される処理の記述方法は次のとおりです。

1. 処理に必要なデータを得る
2. 非メインスレッドに遷移し、処理を行う
3. 処理結果の反映を行う

特に、必要なデータや処理結果の反映にワールドやエンティティが含まれる場合は、データの取得と反映をメインスレッドで行う必要があります。これはBukkitによる制約で、私達ではどうすることも出来ません。

型チェック・キャストを使わない

asInstanceOfとisInstanceOfはできるだけ使わないようにしましょう。Javaのキャスト演算子、instanceof演算子と同様の危険性および非効率性があります。最悪の場合全く関係ない型にキャストすることによってClassCastExceptionが発生し、サーバーが落ちる危険性があるので避けられる場合は絶対に使わないでください。 shapelessなどのコンパイル時型プログラミングを積極的に活用するのも良いでしょう。

もしどうしても使わなければならない場合は、注意して影響範囲を最小限に押し込めるとともに、そこへのフローをできる限り制限してください。

---

※以下は、2023年7月25日現在の情報であり、古くなっている可能性があります

メニュー画面を実装するためにInventoryClickEventを使わない

InventoryClickEventはメニュー以外のインベントリ (例: チェスト) を操作したときも拾ってしまうため、メニューを実装するためにホックすることは推奨されません。 代わりに、Menuを使ってください。

「サブシステム」へ分割、依存、及び準拠する

SeichiAssistには複数の関心事があり、その大半が「サブシステム」と呼ばれるひとまとまりとしてcom.github.unchama.seichiassist.subsystems以下にまとめられています。 最新の一覧

各サブシステムはそれぞれ他のサブシステムなどで使うことを想定したAPIをtraitとして持ち、各サブシステムはその抽象に対してのみ依存することができます。サブシステムの実装はAPIに具象的な実装を与える必要があります。APIの名前はおおよそApiかAPIで終わります。

関心事同士の依存 (例: 整地スキルによってマナを減少させるためにマナを操作する) は 抽象の型をimplicitパラメーターとして渡すことにより表現されます。

新しくサブシステムを作った場合、SeichiAssist.scala内で初期化することを忘れないでください。初期化を忘れると正しく機能しません。

サブシステムの構造は慣例的に次のようになっています。新しくサブシステムを作る場合は一貫性のためにこの構造に準拠することが推奨されます。

• (サブシステムのルート)
  • application - タスク、データのレポジトリの初期化・終了処理など
  • bukkit - Bukkit固有の実装
    • commands - Bukkitのコマンド
    • listeners - Bukkitのイベントリスナー
  • domain - モデル
  • infrastructure - インフラ (JDBCによるデータベースへの保存・読み込みなど)
  • subsystems - 子サブシステム
  • System - サブシステムの「親分」