この記事を読んでちょっと思ったこと。
インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレームワーク自体が独自のものであったりすれば、じんわりと汗が滲み、異様に長大な関数やファイルがあったり、コピペが横行しているところを発見すればほぼ確実である。
クソコードだ。
とプログラマは呟く。
コードの体裁に関するものはわかりやすい
- インデントがおかしい・統一されていない
- 変数名が a, b, c など意味があるものになっていない
- DRY原則に反している（大量のコピペ、if, switchなど）
こういった類の「クソコード」は簡単に検出できるし、意識すればすぐにこういうコードを書かなくすることはできる。
しかし、設計に対するクソコード はどうだろう？
「自分の設計は完璧だ！自分はクソコードを書かない！」 と言い切れるかどうか。少なくとも自分は無理だ。その時考えた最良の方法を選んでいるつもりでも、うっかりだったり、後々のことを考えてなかったり、悪い設計をすることはあるだろう。
「難しすぎる実装」はクソコードと呼べるか
たとえば、
「誰かがメタプログラミングで実装した部分が読みにくすぎる。これはクソコードだ！」
といった主張は正しいのだろうか？
- たとえば boost は（少なくとも自分は）読みづらいが、広く使われている
- しかし、boostの内部実装を読む機会もないので、「これはひどい！！」と苦しめられることは、今はない
- 上の「誰かが実装した部分が読みにくい」というのは、そのコードを読む必要があった場合である
- そのコードを読む必要がある＝不具合がある or 改修する必要がある 場合のみだとおもう
難しい実装が信頼できるライブラリという枠の中に閉じ込められていれば、大丈夫 ということか・・。
まとめ
- 失敗するとやばい開発では、巨人の肩に乗る（信頼されているライブラリを使って、自分の書くソースコードはできるだけ少なくする）
- 趣味としてやるなら、車輪の再発明してクソコードを生んでも、勉強になればいいのでは
