読者です 読者をやめる 読者になる 読者になる

キンサクプログラマー

お金儲けと技術のメモ

普通のリファクタリング (c言語)

なんだか最近リファクタリングばかりしている気がする。
そういうわけで、リファクタリングというのもおこがましい内容だけど、うんこーどにとっては絶大の効果がありそうな観点をまとめてみました。

呼びまくれまくりヘッダ

プロジェクトのきまり文句のように、インクルードされるヘッダは結構あると思います。
プロジェクトないで一貫して呼ぶ必要のある型定義、環境切り替え用の#defineなどがこれに該当します。
ただこいつは注意が必要で、
「どこからでも呼ばれるから、こいつに書いとけばどっからでも参照できるじゃん」
的な感覚で扱われると、何でもかんでもぶちこまれてしまいます。
(全体では使わないけど、そこそこ多くのファイルで呼ばれそうな関数とか)
こうならないよう、不要な依存は外に出しましょう。
聖域として扱ってあげてください。

関数名・変数名

うんこーどはたいてい変数名・関数名がやたら短いです。
長すぎるのはよくないにしても、短すぎるのもまた良くないことを思い出して下さい。
関数・変数の役割として適切名前をつけるべきです。
また、つけた後に確認して欲しいのが、「類似名の関数・変数」の存在です。
そこそこ良い名前がつけれても、類似名のものとの使い分けができなければ結局意味がありません。

無駄な条件文

以外とやってしまいがちなのが、条件文の氾濫です。
一階層上で判断した条件文を、次の階層、次の次の階層で再度判断したりしていないでしょうか。
可読性・サイズ・速度全てにおいて無駄なのでやめてください。

コードクローン

うんこーどはコピペが多いです。
リファクタリングを実施する際は、コードクローンがないかを探して(ツールor手動)
置き換えを考えることが先決です。これだけで、行数を減らすことができて理解しやすくなるはずです。

モジュール分割

うんこーどは99%の確率で、関数がクソ長いです。
初心者の多くは、関数分割する手間を嫌い、長い名前をつけることを嫌い、コーディング時の手間を最大限に考えてコーディングします。なので必然的に関数が長くなるのです。
機能毎に関数化してみてください。可読性は上がるはずです。

ファイル分割

うんこーどは99%の確率で、ファイルもクソ長いです。
こいつも同様に、一つのファイルに役割をもたせすぎです。
スコープが広がりすぎてしまうので適度に分割してください。