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

#はじめに

こんにちは！

今回は業界経験が浅い方向けに、日々のコーディングで意識していることを展開してみたいと思います。
偉そうに言っていますがもうすぐ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?!
	***********
}

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

それではこの辺で。

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