はじめに
プログラミング初心者による記事です。 なお、インデントや=の位置は、基本的にチームのコード規約に沿って書くのがベストです。
コードの比較
# =の位置を揃える foo = 'foo' hoge = 'hoge' hogehoge = 'hogehoge' # =の位置を揃えない foo = 'foo' hoge = 'hoge' hogehoge = 'hogehoge'
前者の方が見やすいですよね。僕もそうなんですが、数学が好きだった人は、=
を揃える方が何かと気持ち良いかもしれません。
=
を揃えることによるデメリット
しかし、揃えてしまったがために、面倒くさいデメリットがあります。
それは、変数名を変えた際に再度=
を揃えなければいけないことです。
# 変更前 foo = 'foo' hoge = 'hoge' hogehoge = 'hogehoge' # 変更後 foo = 'foo' hoge = 'hoge' hogehogehogehoge = 'hogehoge'
hogehoge
をhogehogehogehoge
に変更をしたことで、=の位置がずれてしまいました。
例では3行程度しかないので良いですが、実際のコードでは直すのに大変な手間になってしまうでしょう。
もしかしたら拡張機能や、その他エディタの機能を利用して簡単に修正できる方もいらっしゃるかもしれません。 しかし、その場合でも次のようなデメリットが生じます。
レビューも面倒くさくなる
GitHubでの話となりますが、GitHubではPullRequestを出した際、前回のコミットとの差異を示してくれるFiles changed
という機能があります。
もちろん人によりけりですが、基本的にここを見ないことはないと思います。
ちゃんと細かい差異まで見てくれるので、「1文字消した・増やした」レベルまでも色でハイライトされて表示されてしまいます。
さぁ、ここで『変数名が変更されたから=の位置も全部揃えなおそう!』なんてやってしまうと、FilesChangedは大量の赤と緑で塗られた画面となってしまいます。 なぜなら=を揃えるために追加・削除した空白文字も、"変更点"としてGitHubは拾ってしまうからです。
変数名を1つ変えただけなのに、大量の変更点が表示されてしまったら、レビュワーとしては見づらくてたまらないですね。
さいごに
初めにも言いましたが、あくまでチームの方針に則った書き方をするのがベストです。
ちなみに僕は「リーダブルコードにそんなことが書いてあったぞ!」で意気揚々と=の位置を揃えて悦に浸っていました。 無知の頑張りは怖いものです。