回答編集履歴
2
誤字修正
answer
CHANGED
|
@@ -19,12 +19,12 @@
|
|
|
19
19
|
str.upcase! # => RuntimeError: can't modify frozen String
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
しかし、文字列
|
|
22
|
+
しかし、文字列というごく一般的なデータを取り扱うために都度freezeを付けるのは面倒臭い + freezeが必要/不要を考えず、文字列に片っ端からfreezeを付ける実装が跋扈してきたということから、**「そもそもデフォルトで文字列をimmutable(破壊的な変更不可)にしてしまおう」**という方針が、ruby3.0以降で**決定**しています。
|
|
23
23
|
[ [Ruby] Ruby 3.0 の特大の非互換について](http://d.hatena.ne.jp/ku-ma-me/20151004/p1)
|
|
24
24
|
|
|
25
25
|
そして、将来ruby3.0がリリースされた時にruby2.x系からスムーズに以降できるよう、「デフォルトでStringをimmutableにする」という機能をruby2.x系で限定的に取り込んだのがfrozen_string_literalというマジックコメントです。
|
|
26
26
|
|
|
27
27
|
### frozen_string_literalの対応
|
|
28
|
-
私は原則、rubocopの指針に従ってfronze_string_literal: trueをソースコード内に追加するようにしています。その方が、将来バージョンアップ時の手間が減る(ruby3.0では、frozen_string_literal
|
|
28
|
+
私は原則、rubocopの指針に従ってfronze_string_literal: trueをソースコード内に追加するようにしています。その方が、将来バージョンアップ時の手間が減る(ruby3.0では、frozen_string_literalは単なるコメントとして扱われる予定)ことと、デフォルトでimmutableにした方が予期せぬバグを抱えにくいからです。
|
|
29
29
|
ただ、config系のファイル、テストコード、migrationファイルはrubocopによるチェックの対象外としています。
|
|
30
30
|
migrationファイルはほぼrailsで自動生成したものをそのまま使う、configはそもそも設定を書き下すだけでデータ操作はしない、テストコードは実際の動作に関わらない、といった理由から、そこまで厳密なコーディングをしなくても良いだろう、という判断です。
|
1
サンプルコード修正
answer
CHANGED
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
|
|
9
9
|
print str, str2 # => testtest
|
|
10
10
|
str.upcase!
|
|
11
|
-
|
|
11
|
+
print str, str2 # => TESTTEST
|
|
12
12
|
```
|
|
13
13
|
|
|
14
14
|
一般に、オブジェクトの破壊的変更はコードの可読性を下げ、バグを誘発する傾向にあります。あるオブジェクトをコードのどこかで破壊的に変更すると、そのオブジェクトを参照している箇所全体に影響を与えるからです(上記コードのstr/str2の関係)。
|