ハリーポッター シリーズの中で、アズカバンの囚人がダントツで好きなばぁどです。
wizardingworld の好きなところとして、自分が知らない魔法界のワクワクが描かれているところで、次作炎のゴブレットからはVS闇の魔法使いが色濃くなるので、ファンタジー映画として楽しむ上ではアズカバンが一番好みであります。 本記事のタイトルは、アズカバンの囚人で闇の魔術に対する防衛術でリーマス・ルーピン先生が教えてくれた呪文です。
ソースコードは可読性が命です。
ソースコードは可読性が命です。 ソースコードは書く時間より、読む時間の方が多いというのはよく聞く話です。
例えば既存コードの改修であればどういった動きをするかを読む必要があります。 また数ヶ月前に書いたコードなんていうのは、コードの細部の仕様まではっきり覚えていることはありません。 仕様を覚えていなければ、再度ソースコードを読み込む必要があります。
よって、ソースコードは読みやすいことがとても大事です。
馬鹿馬鹿しいコード
エンジニアとして働いて7年。 数多くのソースコードを読んできましたが、今まで思わず画面を見ながら突っ込んでしまったソースコードにたくさん出会ってきました。 ソースコードを読んでいる時の様子を見られて、常駐先のお客様に「なんだか今日は楽しそうだね」と言われてしました(恥
そんな僕をびっくりさせてくれた、馬鹿馬鹿しいコードを紹介していこうと思います。
これはmain関数です
バカバカしいコードのお手本のようなコードでした。 そう言った教科書があれば、ぜひ掲載したい。そんな本番で動いていたコードです。
# main method def main(): hoge = 'hoge'
main関数という名前がついているのに、「これはmainです」という看板が建てられている。 「はっ!!!進研ゼミで見たことある!」と言わんばかりの、リーダブルコードに書かれているお手本のようなコードでした。
main関数が、main の関数であることなんて知っているわ!!!! mainじゃなければ、あなたは誰??? と、思わず画面に向かって突っ込んでしまいました。
あなた達の名前は順番に上からa, b, c, d, e
五つ子のように、上から順番にa, b, c, d, e という変数がつけられたコードを見たときは驚愕しましたね。
class Hoge(): def __init__(self, param_list): a = param_list[0] b = param_list[1] c = param_list[2] d = param_list[3] e = param_list[4]
で、あなた方は何者なの? 名前が贅沢だから取られてしまったの?ここは温泉宿なの?千なの?
この変数名では生まれてしまった変数達が可哀想です。 キラキラネームであっても必ず親から子へのメッセージが託されているのに、これに関しては意味がないですからね。
変数の名前はしっかりと意味のあるものをつけてあげてください。お願いします。
君は東京-大阪間を飛行機に乗って高速道路を爆走している
DjangoのViewのコードです。 DjangoではControllerをViewと言います。Djangoでは、MTV(Model, Template, View)です。 他のフレームワークにおける Controller です。MVCのCを担当しているのがView。 本来であればViewには、DB接続という概念はありません。 それらはModelが担当しており、ViewからはModelを介してDBにアクセスを行います。
しかし、私が出会ったコードは私の常識を遥かに超えていました。
def post(self): sql = ''' SELECT hoge_column FROM moge_table WHERE piyo = ''' sql += query result = dao.execute(sql) return result
Viewの中でSQLを直打ちしているだと・・・・ Modelは????? MTVモデルの意味。 しかもsqlを文字列連携している・・・
これはDjangoの使い方、Webアプリフレームワークの使い方を理解していない人のコードですね。
飛行機による移動手段は主に飛ぶことなんだよ。 飛行機にタイヤがついているからと言って、東京-大阪間を高速道路で移動しないのだ。(別にしていいけど、やらないよ)
のこぎりで釘を打ってはいけません。 道具には正しい使い道があります。
クラスの責務を否定するクラス
class ParameterClass(): def __init__(self): pass def get_hoge(self): return self.hoge def set_hoge(self): self.hoge = hope def get_moge(self): return self.moge def set_moge(self, moge): self.moge = moge class Hoge(): def __init__(self, param): self.param = param def get_hoge(self): return self.param.hoge def set_hoge(self, hoge): return self.param.set_hoge(hoge) class Moge(): def __init__(self, param): self.param = param def get_moge(self): return self.param.moge def set_moge(self, moge): return self.param.set_moge(moge)
数年前に見たコードなので若干曖昧ですが・・・ おそらくクラス間で共有したい値を引き回すためのクラスを作ったのだろうと察しましたが、それにしてもクラスの責務を大幅に逸脱しているコードでした。
最初見たときにクラス間の責務をぶち壊すような縦串を通すようなクラスであるParamClassにびっくりした覚えがあります。
クラスにはそれぞれ責務があって・・・(疲
これらバカバカしいコードに対する防衛術
ソースコードレビュー
Git が素晴らしい。 Pull RequestやMerge Request などGit サービスによって言い方は変わりますが、それらの機能を用いてソースコードレビューをしましょう。
極稀に2人での開発だから、レビューしなくていいよねという発言が聞こえるのですが、複数人になった時点でレビューは徹底しましょう。
レビューをすることで、俗人化しやすいプログラミングという仕事を少しは緩和することができます。 他人のソースコードレビューをすることで、その人のプログラミングの癖を知り、新しいプログラミングの表現方法を発見できるかもしれません。 もちろん、ソースコード上のバグの指摘や、仕様ミスにも気づくことが可能です。
ソースコードは言葉です。ソースコードを通しての会話はプログラマ同士のコミュニケーションです。
リーダブルコード
読も! プログラマにとってのバイブルですよ!
本記事のいくつかは、リーダブルコードに書かれていることです。
まとめ
リディクラスはものまね妖怪ボガードを退治する呪文です。 しかし、この馬鹿馬鹿しいコード達は何も退治してくれません。 強いていうなら、優秀なプログラマを退治(退職)させることはできるかもしれません。
リディクラスは馬鹿馬鹿しいコードという意味で付けさせていただきました。 さぁ、馬鹿馬鹿しいコードを見つけたら唱えましょう!リディクラス!!
※リディクラスが言いたいだけの記事でした。すみません。綺麗なソースコードは大事です。