スクラッチコーチのコーディング規約

スクラッチに挑戦している皆さん、どうも！スクラッチコーチです。

スクラッチのチュートリアルで使われているスクラッチコーチのコーディング規約をまとめておきます！

コーディング規約とは？

コーディング規約というのはシステム開発やゲーム制作の現場ごとに定義されている「どうやってコーディングするか」というルールのことです。

例えば変数名の付け方

たとえば最近のIT現場における変数の名前に関するコーディング規約だと、キャメルケースとスネークケースのどちらかが多い印象です。

• キャメルケースとは……「scratchGameDevelopment」のように、「scratch」「game」「development」という文字のつなぎ部分を大文字にする書き方。ただし最初の文字は小文字。キャメルというのはラクダのことで、文字の感じがラクダのコブっぽいという由来。かわいい。
• スネークケースとは……「scratch_game_development」のように文字のつなぎにアンダーバーを使う書き方。なんとなくヘビっぽいからという由来。

個人的な感覚だとJava、Javascript、Python、Rubyなどの最近メジャーな言語ではキャメルケースのほうが多いかな。スネークケースはPHP（とくにWordPress）でよく使われている印象。

スクラッチだと日本人は変数名は日本語で付けたほうが分かりやすいと思うから、キャメルケースは使えないし、スネークケースもそこまで使われてないかな。

スクラッチのコーディング規約

ココからは実際にスクラッチコーチで使っているコーディング規約をまとめておきます！

変数名

基本的に変数名は日本語で書きます。ただしXやYなど、英語のほうが分かりやすい部分は英語を使います。

変数の種類を見分ける書き方

スクラッチには大きく２通りの変数があります。

• すべてのスプライトに共通の変数（グローバル変数）
• このスプライトでのみ使う変数（ローカル変数）

公式のこの２つに加えて、さらにもう２つスクラッチコーチでは独自に定義しています。

• １度だけ値をセットしたら２度と変更しないグローバル変数（定数）
• このスプライトのみで使う上に、あるブロック定義内でのみ使われる一時的な変数（プライベート変数）

これらを見分けるために以下のように接頭語を使っています。

種類	接頭語	例 (カッコ内は値の例)
グローバル変数 （すべてのスプライトで使う変数）	★	★重力 （-1など） ★難易度 ★いまのステージ
定数 （１度定義したら変更しないグローバル変数）	■	■はい　（1） ■いいえ　（0） ■あり　(1） ■なし　（0） ■30FPS　（30） ■空白　()
ローカル変数 （このスプライトのみで使う変数）	なし	スピードY ジャンプ力
プライベート変数 （このスプライトのみで使う一時的な変数）	_	_値 _一時的に保存された速度

英語圏のスクラッチャーさんは、グローバル変数は大文字で書いて、ローカル変数は小文字で書くようにしてたりする。みんなそれぞれコーディング規約があって、見てて面白い。

真偽値を格納する変数

変数の値が0か1（falseかtrue）になる変数は接尾語を「〜かどうか」にします。長過ぎたら「〜か」でもOK。

例）ジャンプ中かどうか

例）空中にいるか

ブロック定義名

基本的にブロック定義名は日本語で書きます。

ブロック定義名は動詞で書きます。

例）ジャンプを行うブロック定義であれば、「ジャンプ」ではなく「ジャンプする」「飛ぶ」「跳ねる」など

再描画するブロック定義かどうかを見分ける書き方

ブロック定義には再描画するものとしないものがあります。パッと見ただけで分かるように接頭語を付けて判断します（最近そうし始めました）

種類	接頭語	例
再描画が必要である	なし	ジャンプする アニメーションする
再描画が不要である	_ （アンダーバー）	_空中にいるか調べる _スピンできるか調べる _埋もれを修正する

引数は引数名をラベルでも書く

ブロック定義には引数を渡せますが、この引数名を敢えてラベルでも書き残しておきます。

たとえばコレ↓

「値」という引数が定義されています。そして「エンコードする）値：」というように「値：」という引数名を敢えてラベルにも書いてあります。この状態だと冗長に思えますが、実際にブロック定義を使う時に便利です。

見てみましょう↓

↑このように引数は空白になってしまいます。そうすると「あれ、ここって何いれるんだっけ？」といちいちブロック定義の引数名を調べる必要があります。そのひと手間が面倒なので、最初からラベルに引数名を書き残しておきます。

プライベートブロック定義

長いブロック定義を小分けするために、処理の一部を別のブロック定義に移し替えるというリファクタリング上の理由で作ったブロック定義をプライベートブロック定義と個人的に呼んでいます。

プライベートブロック定義には、呼び出し元のブロック定義名 + アンダーバー２つ + 動詞という命名規則を採用しています。

例）「_キー操作[←→]に対応する」の処理が長いので、止まる処理は別途切り出して別のブロック定義としてまとめたなら、そのブロック定義の名前は「_キー操作[←→]に対応する__止まる」となる。

こうすることでブロック定義一覧では並んで表示されるので後日見ても「これはプライベートブロック定義だな」と一目でわかります。

メッセージの書き方

基本的に日本語で書く。最近は不自然でなければ語尾は「〜します」「〜しました」で整えています。

例）ゲームを開始します

例）被弾しました

例）停止ボタンが押されました

例）ステージをクリアしました

条件分岐やループなどの囲みは極力ネストさせない

ネストというのは「もし〜なら」の中でさらに「もし〜なら」を使うこととか、「ずっと」ループの中で「もし〜なら」を使うことです。ネスト自体は悪いことじゃないし、むしろ絶対ネストしないと無理な場面って多い。

だけど「もし」の中で５回も６回も「もし」が使われてたりすると、すごく見づらくなります。

こんな↓

こういうのを「ネストの階層が深い」と表現するのですが、階層が深すぎるとデバッグが大変になりがちです。

• なんで「もし」の色が違うの？

  上の画像は「もし」の色がオレンジと黄色になってて、ネストしても少し見やすくなってます。これはグリフパッチさん達が開発してくれているスクラッチアドオンというChromeアドオンのおかげです。気になる方はチェックしてみてください。

そこで、可能ならネストは極力しないように作れるように心がけてます。可能なら！

↑左と右のブロック群はまったく同じ処理なんですが、どっちが好みですか？好みにもよるのですが、左はネストをさせないようにしたバージョン。右はネストしまくってるバージョンです。処理の内容自体は全く同じですが、左のほうが個人的には好みです。

コーディング規約を作っちゃおう

これは僕なりのコーディング規約ですが、みんな「オレオレ規約」作ってしまってOKだと思います！別に仕事じゃないんだし、自分なりのスクラッチの作り方ベストプラクティスみたいなのを作るのも楽しみなんじゃないかなぁって思います。