#はじめに
Railsで開発をする際にslimを使っていましたが、元のerbに戻すことにしました。本記事ではslimのメリットとデメリットを比較し、slimからerbに戻した理由について説明します。
#slimとは？
slimはRailsで使うテンプレートエンジンの１つです。slimを導入することで、通常のhtmlよりも記述量を減らすことができます。
例えば、次のように< >と閉じタグは省略されます。
<div>
<h1>メニュー</h1>
<ul>
<li>Ruby</li>
<li>on</li>
<li>Rails</li>
</ul>
</div>
div
h1 メニュー
ul
li Ruby
li on
li Rails
詳細な文法は↓にリンクを貼っておきます。
#slimのメリット
slimを導入すると以下のメリットがあります。
・書きやすく読みやすい最小限のテンプレート
・デフォルトでHTMLエスケープを行い、セキュア
要するにコードを短く書けるようになるということです。
#slimのデメリット
上ではslimのメリットについて記述しましたが、一方で以下のデメリットがあります。
・デフォルトでない
・細かいところは都度調べる必要がある
簡単に書けて記述量を減らせるのがslimのメリットでしたが、基本的な文法から外れるなどの細かい書き方をする場合、その度に調べる必要がありました。その調べる時間を考慮すると、記述量を減らせることによる時間短縮を上回りました。また、時間だけでなく、何度も詰まり調べなくてはならないことにより、大きく開発体験が損なわれることも体感しました。
リーダブルコードの1.2「読みやすさの基本定理」には以下のように書かれています。
コードは他の人が最短時間で理解できるように書かなければいけない。
ここでいう「他人」には自分も含まれています。書いているときにはslimの文法を覚えていても少し時間が経てば、完全に覚えているということはないでしょう。少なくとも僕はその自信がありません。そうなると、長期的な目線ではデフォルトのhtmlで書くほうが可読性が高いでしょう。自分だけでなく他人も開発に参加する場合、その都度slimの文法を学んでもらう必要があります。この点においても、可読性が下がっていることがわかります。
また、1.3「小さなことは絶対にいいこと？」では、コードはただ短ければ良いことなのかということに疑問提起をしています。ただ短いだけのコードより、長くなったとしても読みやすいコードのほうが良いとしています。重要なのは「理解するまでにかかる時間」を短くすると結論づけています。これは先程の議論と同様にslimの場合に対してもあてはまります。
#おわりに
以上の理由により、slimからerbに戻しました。slimのメリット、デメリットを比較するにあたり、コードの読みやすさ、開発体験などを改めて考えることができました。
#参考