はじめに

こんにちは！

今回は業界経験が浅い方向けに、日々のコーディングで意識していることを展開してみたいと思います。
~~偉そうに言っていますがもうすぐ4年目のぺーぺーですｗ~~

当たり前だろってことを書いていますが、温かい目で見て頂けると幸いです。。。

プログラム

変数や関数の命名規則を守る（整える）

キャメルケースとスネークケースが混同しているソースコードをよく目にします。

キャメルケース

$camelCase = checkNameStyle($inputStr);

スネークケース

$snake_case = check_name_style($input_str);

プロジェクトや現場ごとにコーディング規約がある場合はもちろんですが、
実際に明確に定まっていない場合もあり、好きに書いても何も言われない場合もあります。

ですが、だからと言って自分の好きなスタイルを押し通すのではなく、
改修案件の場合は既存のソースコードに則って改修を行う、
新規案件の場合は統一性をもって事前に各メンバーに展開する等を行っています。

ちなみにですが、私が新規で開発を行う場合、
特に指定がなければ使用言語や使用フレームワークの命名規則に則ることを意識しています。

ネスト（入れ子）を深くしすぎない

これは単純にソースの可読性を上げるために意識しています。

ネストが多いソースコード

$hoge = $this->getHoge();

if (!empty($hoge)) {
    foreatch($hoge as $val) {
        if ($val == "success") {
            echo "O.K.";
        } else {
            continue;
        }
    }
} else {
    return;
}

ネストを少なくしたソースコード

$hoge = $this->getHoge();

if (empty($hoge)) {
    return;
}

foreatch($hoge as $val) {
    if ($val != "success") {
        continue;
    }

    echo "O.K.";
}

どちらも出力結果は同じですが、パッとみた感じどっちが読みやすいですか？

ネストを少なくしたソースコードの方が理解しやすいんじゃないかなと思います。
今回は数行のソースコードであまり恩恵はないかも知れませんが、
実際の業務となってくると、体感できるレベルで差を感じることができると思います。
また、自分が読みやすい=他人が読んでも理解しやすいということになるので、
自分以外の人が改修を行うときも活きてくるとおもいますよ！

異常パターンは早めに返却

先ほどのネストの部分に通ずることが多いのですが、
ソースコードの前半で異常パターンであるならば、処理をその時点で返却している方が可読性が上がります。
異常パターンの処理をelseに入れてしまうと、ソースコードの下の辺りにいってしまい、
「あれ、この処理どこの分岐だっけ？」
と見返す手間が増えたり、そもそもネストが深く見違えてしまう可能性も0ではありません。

なので、可能な限り先に異常パターンを返すといいかなと思います。

関数を記述する位置

これは同系統の関数を並べて配置することによって、
可読性や保守性を上げるために意識しています。

改修案件が入るたびに崩れやすい部分になります。

整理されたソースコード

public function getA() {
    ***********
}

public function getB() {
    ***********
}

public function getC() {
    ***********
}

public function setA() {
    ***********
}

public function setB() {
    ***********
}

public function setC() {
    ***********
}

public function updateA() {
    ***********
}

public function deleteA() {
    ***********
}

まとまりがなく散らばったソースコード

public function getA() {
    ***********
}

public function getB() {
    ***********
}

public function setA() {
    ***********
}

public function setB() {
    ***********
}

public function deleteA() {
    ***********
}

public function updateA() {
    ***********
}

public function getC() { // get?!
    ***********
}

public function setC() { // set?!
    ***********
}

まとめ

いかがでしたでしょうか？
まだまだあると思いますが、動くものが作れるようになったら次のステップとして、
可読性や保守性を考慮したソースコードにチャレンジすることも面白いのではと思います。

それではこの辺で。

最後までご覧いただきありがとうございました。

普段コーディングで気をつけていること