良いコードの書き方について考えてみる

はじめに

先日、”良いコード/悪いで学ぶ設計入門”を読みました。

本書で触れられていた内容について、この記事ではPythonコードでの具体例を交えながら、紹介したいと思います。

一部紹介になりますので、ぜひ本書の購入して読んでみてください。

ベタ書き禁止

# これはベタ書きされた良くない書き方
import pandas as pd

df = pd.read_csv('test1.csv')
df = df['name', 'address']
print(df)

のように、関数化されていないベタ書きはやめようという内容です。

適切な塊ごとに関数に分けて、適切な関数名を与えるべきです。

# 関数化された適切な書き方
import pandas as pd


def read_csv(filedir: str) -> pd.DataFrame:
    return pd.read_csv(filedir)


def select_columns(df, column_names: list) -> pd.DataFrame:
    return df[column_names]


df = select_columns(read_csv('test1.csv'), ['name', 'adress'])

多重If分の滅ぼし方

多重If分は悪です。

if a > 1:
    if b > 2:
        if c > 3:
            pass
        elif c > 10:
            pass
        else:
            pass
    else:
        pass
else:
    pass

こんなコードを見つけたら駆逐しましょう。

１つ目は、早期のreturnです。

if isCorrect:
    return 
if isChange:
    return 


if a > 1:
    pass

のように、ロジック対象以外の入力条件についてはifのネストによって解決するのではなく、事前にifの対象から外すことで可読性の高いプログラムにすることがきできます。

もう一つは、interfaceです。本書では、Javaを用いて記述されており、オブジェクト指向について理解がないと狙いと意図が掴めないと思いますので、簡単に言い換えるならば

単一責任選択の原則に習い、コアロジックを記載するClassを一つ定義し、そのクラスをInterfaceとすることでそれ以外のクラスではそこから使う

ということで、ロジックの分散を塞ぎ全体の可読性を上げることを目的としています。

設計の悪魔たち

ここでは、クソコード・クソ設計にならないように注意することをまとめます

YAGNI原則

YAGNIとは、「You aren't goin to need it.」ということで実際に必要になったときにのみ実装せよという方針です。

仕様が確定していないのにもかかわらず、エンジニアが気を利かせて作るようなことはやめましょう。ということが狙いです。

マジックナンバー

for item in range(10):
    pass

紹介不要かもしませんが、このような狙いがわからない数字は絶対にやめましょう。

ALL_ITEM = 10
for item in range(ALL_ITEM):
    pass

などとしなければいけません。

例外の握りつぶし

try {
    val = 1
} except {
    pass
}

のようななにもしないexceptは禁止です。

問題が検出されたときはけたたましく叫ばせましょう。

いい名前をつける

def method1():
    a = 1

def method2():
    b = 2

def method3():
    c = 3

のように、何をする関数かわからない関数や変数名は禁止です。

本書では、目的駆動名前設計と呼ばれるようなテクニックもありますが、まずは意味のわかる関数名をつけること。特に、動詞一語でできるだけ表現するとベストです。

また、nullは使わないであったり、フラグ引数は使わないなども覚えておくといいと思います。

良いコードを作るために

ここでは良いコードを作るために日々考えることを記載していきます。

木こりのジレンマ

森の中で、木こりが刃のこぼれた斧で一所懸命に木を切っていた。通りかかった旅人が『刃を研ぐともっと早くたくさんの木を切れますよ』と言ったところ、木こりは『木を切るのに忙しくてそんな暇はないんだよ』と返事をした

ご存知でしょうか。目先の実装に目が取られて中長期的な良いコードを書くための設計等がなされていないと、結局は生産性の低下になります。

常に少しづつ改善していきましょう。

Yuta NakataのBlog

Python / AWS / ITについて役立つ情報を発信します