はじめに
GDScriptの記述において、以下のように式の見た目(列)をそろえるための空白やインデントは、非推奨とされます。
x = 100
y = 100
velocity = 500一見すると見やすくも感じられますが、結論としては可読性と保守性を下げる要因となってしまいます。
以下に、その内容についてまとめていきます。
なぜ、可読性や保守性が低下するか
前述のような記述を行った場合に発生しうる問題について、いくつかの例を以下にまとめます。
1. 差分(diff)が汚れる・レビューしづらい
Git等のバージョン管理を行う場合、変更が発生した場合には差分の履歴を閲覧できますが、
以下のように空白のズレまで差分として出てしまいます。
- x = 100
+ x = 100結果、以下のような問題が発生します。
- Git の差分がノイズだらけ
- レビューで本質が見えにくい
- マージコンフリクトが増える
2. 変更に弱く、保守コストが高い
一貫性を保つためには、最長となる新規変数を1行追加しただけで、全行の空白を調整し直す必要が出ます。
x = 100
y = 100
velocity = 500
acceleration = 20 # <- 新規追加これは単純に調整作業が増えることとなりヒューマンエラーの原因にもなりえます。
3. フォントや環境によってズレる
使用するエディタや環境、使用するフォント設定によってインデントがずれるケースもあります。
チームで開発を行う場合、これによって環境依存となる要素ができてしまうため、可能な限り避けるのが無難です。
完全に禁止すべきか
上記のような理由で、見た目をそろえる目的の空白やインデントは使用しない方が無難ですが、以下のようなケースではデメリットを考慮したうえで使用を検討する余地があります。
テーブルデータ(ログ・定数表)
以下のように、定数を羅列するような形で、データテーブル的意味があり、「列(カラム)」のような情報を扱いたい場合は、揃えることで記述にその意味を持たせることができます。
(構造的な部分のため、列挙型や辞書型等でまとめられる場合はそちらを優先した方が有利ではあります)
ITEM_HP = 100
ITEM_MP = 30
ITEM_ATTACK = 5説明表コメント
以下のように、「値」と「説明」が対応している記述では、可読性の面でのメリットが大きいため、検討の価値があります。
x = 100 # player x
y = 200 # player y
z = 0 # depth