コードは読めなければならない
ストレス発散がてら書いたネガティブな愚痴り記事が思いの他ブクマしていただくことになり驚いている。みなさん苦労されているようですね。コメントなども多数頂戴したので、調子に乗って返答記事などポストしてみる。*1
コードは読めなければならない
自分のスタンスを明確にしておこうと思う。
コードは読めなければならない。*2
UKTKKNSHINFがダメな理由は、それが読めないからである。頑張って慣れれば読めないこともない、というものは話にならない。容易に読めなければならない。
それに規則性があるなら他のプロジェクトにも転用できない？母音抜きルールを。
UKTKKNSHINFコンバータ作りました、それとUKTKKNSHINFってそんなにひどい？ | さくらたんどっとびーず
他に転用できるんだったら、全社的な生産性向上に寄与できるんじゃないの？母音抜きルールで。
規則性があればよいのであれば、プログラミング言語なんて余計なものを挟まずに、マシン語を使うのはどうだろう。マシン語は読みづらいが、規則性があり、慣れれば読めないこともない。他のプロジェクトにも転用できて、生産性向上に寄与できるであろう。
本当に？
規則性があるだけではダメなことは明白だと思う。人にとって読みやすくなければならない。読みやすさが重要だから、アセンブリ言語が生まれ、プログラミング言語が生まれたのである。読みにくくてもよい、人間側が慣れれば済むことだ、そう考えるのであれば、「それじゃマシン語でやれる？」と自分に問いかけて欲しい。読みづらいコードは、存在意義を失っている。*3 *4
まぁ、可読性の高いコードを書くことの重要性はCode Completeをはじめとしてあらゆる書籍、あらゆるサイトで説明されているので、これ以上は書かない。
したがって、
idesaku 様はローマ字オッケー派みたいだけど、受付禁止情報なら uketuke_kinsi_inf とかならよろしいのかしら？それとも uketuke_kinsi_joho？もしくは UketsukeKinshiJouhou？
UKTKKNSHINFコンバータ作りました、それとUKTKKNSHINFってそんなにひどい？ | さくらたんどっとびーず
どれでもいいと思う。どれも読めるからだ。
T5001（意味はExcel管理）とか日本語のテーブル名だったら？
前者はダメである。読めないから。というか、なんでそんなIDを使う必要があるのかわからない。後者は読めるのでOKなのだが、テーブル名に日本語を使ったりするといろいろ面倒が起きそうなので、別の理由で却下するかもしれない。
フラグ変数にflgとかつけちゃうなあ…
OK。読める読める。俺もControlをCtrlにしたりUtilityをUtilにしたりするし。
性別にseibetuならやってる。
OK。読める読める。ただ、個人的にはsexかgenderを当ててほしいかな。
今でこそ英語がわからない俺も常に手元に電子辞書を置いておくか、
和英 ○○でぐぐってすぐ英語の変数書けるからいいですが、
昔はネットにつなげない時代もあったわけで……。
英語がわからなかったら、ローマ字書きしていいと思う。読めるから。もっとも、中学英語レベルの英単語ぐらいは辞書無しでも出してほしいところだが…。
システム設計以前にお客さんの業務の方が複雑化してて名前が長くなっちゃうのよ、お客さん達の呼び方と乖離させる訳にいかないし、と言い訳してみる
言っていることはわかるのだが、乖離させないようにUKTKKNSHINFにしたとして、読めないと意味はないと思うのである。
対策
disるばかりじゃなくて、対策は？という声もあるのだが、対策も何も普通の名前をつけてやってくれ。
- ローマ字書きしたいなら、妙な省略をせずにそのまま書く
- 単語境界を明確にする
- それで30文字*5を超えるようであれば、一つのパッケージor関数が多くのことをやりすぎなので、分割を検討する
何事にも例外はあるので、やむなく変態的な省略形を使って制限を回避することもあるかもしれない。それは仕方がない。しかしそれはまさに"例外"的にごく少数存在するかもしれない、程度のものである。コード全体で同様の問題を抱えるようであれば、それは設計が根本的におかしいと考え、見直しを検討すべきだ*6。
設計の見直しは他に比べて高度で難しい作業だが、それを理由に安直に変態的なネーミングで回避することは間違っている。高度なことができるからこそのプロである。技術的負債を残してはならない。目先ではなくこの先何年も発生する保守コストを意識して可読性を維持するよう努めることは、職業プログラマにとって当然のことではないだろうか。
これは30文字制限があろうとなかろうと関係ない。JavaだろうがC#だろうがRubyだろうが、30文字を超えるような長い名前は基本的に読みづらいため、普通そんな名前はつけないし、つけることが多くなってきたら同様の手段で正常化を図ることだろう。
正常化できるか
一度変態的なネーミング他で汚染されてしまったコードをどう正常化すればよいか？それは俺にもわからない*7。
早期に問題を意識して対策を取っていれば正常化も可能だったろうが、技術的負債は時間の経過により対処コストが指数的に増大するため、ある一線を越えたらもはや対処不能になると思う*8。
そう思うから、常に読みやすさを意識してコードを書かねばならないと指摘するのである。可読性を捨ててとりあえず動くものを書く、なんてことをしていると取り返しがつかなくなるのだ。
正常化不能なコードをどのように読むべきか
がんばれ。というか、そんな都合の良い方法があるのであれば、俺に教えてくれ。心底困っているのだ。変態略語-正常語マップを作って、一括置換するぐらい？リファクタリングの恩恵が得られない環境では、間違ったところを変換しそうで怖いな。
まとめ
- コードは読めなければならない。
- そのためには普通に読める名前をつける。制限回避に安直な手段を選ばず、必要であれば高度な手段でも使う。腕の見せ所。
- 読みづらさを放置しておくとそのうち対処不能になるので、常に読みやすさを意識して書く。
*1:引用元を書いていないものは、元記事のコメントまたはブクマコメから持ってきたものである。Permalinkがないもので、勘弁してください。
*2:読める以前に当然動かなければならないが、それは「歯磨きするときは口を開けなければならない」レベルの、わざわざ指摘するまでもない当然すぎる条件である。
*3:例外はある。読みづらさが本質的複雑性によるものであれば、人が頑張って読むしかない。偶発的複雑性によるものであれば、排除して読みやすさを保つよう努めるべき。
*4:マシン語ではなくプログラミング言語を使う利点は、他にも移植性を始めとしていろいろあることは理解している。単に読みづらい言語の代表として出しただけである。しっくりこない人は自分にとって極めて読みづらい言語をイメージしてほしい。
*5:パッケージと組み合わせれば60文字までいける？
*6:設計のまずさがネーミングに悪影響を与えている、という意見は元記事でも書いた。
*7:PL/SQLのような半ばレガシー化した言語相手だと、リファクタリングも難しいだろう。
*8:だから、元記事では「担当者が無能」とこき下ろしたが、それは不幸にも保守を引き継ぐことになった現在の担当者を意味しない。無能なことがほぼ確実なのは、あくまで最初にコードを書き始めた連中である。
