コーディング規約とかガイドとかって難しいよねという話

注：細かくてどうでもいい話です

Cookpadの規約スタイルガイドについての話
https://github.com/cookpad/styleguide

@r7kamura > ハッシュのキーを Symbol にして良い場合は、文字列よりも高速に lookup できるので積極的に Symbol を使うこと / “styleguide/ruby.ja.md at master ? c…” URL

@r7kamura なんかいきなり無言リプライしてすいません。ここ問題があると思ったんですけど中村さん的にどうですか

@yayugu んー、問題があるって言えるほど知識無いから分かんない。規則じゃなくてガイドだから良いんじゃない？でも確かに、あえてlookupのコストを理由として上げるのはあんまり効果的じゃないね。リテラルで書く場合のキーの数とかC側で配列に最適化されてるレベルの大きさだし

@r7kamura あくまでガイドなのかmustとかshouldとかあるので規約かとおもてた / パフォーマンスにはほとんど影響しないし、symbolはGCされないのでむしろ詳しくない人がこれ見て巨大な文字列集合をsymbolにするようなコード書いちゃうと厄介なバグ踏みそう

@yayugu この数値、正規表現、配列、ハッシュみたいな並び見るにリテラル書くときの話をしてるっぽいね。動的生成でどんどんシンボル生やしていったら確かに死にそう、どんどんリクエストを送ってシンボルを作らせよう

[SHOULD] ハッシュのキーを Symbol にして良い場合は、文字列よりも高速に lookup できるので積極的に Symbol を使うこと。

ここの箇所、言いたいことは分かるんですがちょっと誤解を招くなと思った
具体的には

「可読性と一貫性」*1を目的にしているならパフォーマンスの話をするのはおかしい
ハッシュのlookup速度が問題になるケースはかなり少ないので、一般的な状況ではキーをSymbolにすることにパフォーマンス上の優位点はない
SymbolはGCされないので新しいSymbolがガンガン作られる状況(ex. ユーザからの入力を.to_symする, 巨大な文字列の集合を.to_symしたものでハッシュをつくるなど)ではメモリリーク *2が発生する。

という問題があると感じた。

で、r7kamuraさんに聞いてみたところ
いくつか勘違いしていたことに気づいた