🐡

静的型付言語におけるハンガリアン記法の是非

2023/04/30に公開

概要

新しく着任した現場にて、ハンガリアン記法が多数使用されていて大変冗長だと感じた。
レビュー時に修正を依頼したものの、ハンガリアン記法の旨みは本当にないのか気になったため筆を取った。
現場で静的型付言語を使用していたので、それ前提で話を進める。

名前の前（または後ろ）に属性を表す単語をつける記法のこと
またハンガリアン記法には

val intBookPrice = 200
のように変数名の接頭（または接尾）にデータ型名をつけるものをシステムハンガリアンという
今回出くわしたのは、こっち

名前を見ればデータ型がわかる！というのがメリット。。。
ただ、IDEが整備されている現代避けるのが無難
vimやメモ帳で動的型付言語書いてます、とかだったら良いのかも？

val yenBookPrice = 100
のように変数名の接頭（または接尾）に変数の用途や単位、意味などをつけるものをアプリケーションハンガリアンという

システムハンガリアンに比べるとまだ現代でも使用できそうな記法に思える
こちらは変数名にその意味を表す単語をつけよ、程度のことなので
そういうコーディング規約があってもおかしくはないかも

ただ、本当にそれは変数名の付け方だけで解決すべき問題かは考えたほうが良さそう。
先ほどのお金の単位の話ならそもそも、クラス切ったほうがいいよね？とかあるし

メリットが薄いハンガリアン記法だが、デメリットも見ていこう

どちらのハンガリアン記法にも言えることだが、変数名のメンテコストが高いだろう

そして修正漏れなどがあると、名前と中身が一致しないという自体が起こりうる
型によるエラーの発見もできないので、わざわざ導入するメリットはないだろう

ネットを見るとまだまだありそうだが、パッと思いついたのはこの辺
致命的になりがちなデメリットなのでハンガリアン記法採用しないのが吉だろう

Map型なら、キーto値とすべきだし
List型なら、複数形にすべきだろう

ハンガリアン記法はやめて、型による保護のもとIDEに導いてもらおう

この現代で、ハンガリアン記法使用しているのは「あー変数名考えるのめんどいなぁ、List型だしListってつけちゃお！えい！」
としている背景が多そう。
dataとかtmpとかひどい変数名つける人ほどやりがちな気がする。自戒を込めて気を付けていこう