「見やすい・わかりやすいコードにするために（初心者編）」

例１
“data1” ,“data2”というように同じような名称の変数がある場合は、それぞれのデータの機能や用途がわかりません。
それぞれの用途がわかるように“ ReadData”, “ WriteData”などの名称にします。

その他、“a”という変数をif文の判定に使用する場合、“a”のかわりに“count”とすることで何かのカウントを判定していることがひと目でわかります。さらに“PageCount”とすることで「ページ数」であることがすぐにわかります。
私は、似た変数名が増えて自分が書いたコードにもかかわらず、区別が難しくなり解析に時間がかかった経験があり、変数名は明確にするようにしています。

変数名の先頭にデータ型を示す文字を追加します。
変数名からデータ型がわかるので、間違った処理を書くことを防ぎやすくなります。
例：unsigned char byData; /* unsigned char型のデータ*/

一般的なネーミング規約のひとつにハンガリアン記法があります。
ハンガリアン記法については、ソフテックだより第19号で紹介していますので、そちらを参照してください。
プレフィックスをつけることで変数の型を変えた場合に変数名の修正が必要となり、作業効率が悪くなったり、修正ミスにより不適合を発生させたりする可能性もあります。
そのため、開発言語やプロジェクトにより、ハンガリアン記法を使わない場合もあります。
ただし、ハンガリアン記法を使ったコードは、まだありますので書き方のひとつとして、覚えておいたほうが良いと思います。

関数名や変数名に対称性を持たせることでプログラムがわかりやすくなります。
さらに、解析する際に対となるキーワードが予想できるので、検索しやすくなり、解析効率が向上します。
例
add⇔remove
get⇔set
start⇔stop
up⇔down
read⇔write

タブを使わない場合

タブを使って、インデントをそろえた場合

インデントのサイズを合わせることで、見やすくなり解析ミスを防ぐことができます。
インデントをそろえる方法は、タブとスペースの2種類の方法があります。
インターネットで調べるとスペースを利用する人が多いようですが、私は、開発言語やプロジェクトによって決めています。

ひとつの関数にいくつもの処理を書いていくと、あとからコーディングした本人でも解析が難しくなってしまいます。
このような場合は、get○○○/set○○○、start○○○/stop○○○、read○○○/write○○○というように関数の処理を機能ごとに分割することで、解析しやすくなります。
その他の例として、私は、機能がステップや条件で分かれる場合に条件判断する関数とデータを処理する関数に分けるようにしています。

if文やwhile文などの｛｝を省略できますが、if文が入れ子になる場合は非常に見づらく、解析が難しくなります。

｛｝がない場合

｛｝がある場合

｛｝がない場合、コーディングした人は、1つ目のif文にelse文が対応しているように見えますが、処理としては、囲みの範囲の通り、2つ目のif文にelse文が対応します。
｛｝をつけることで不具合を防ぐことができます。
私の場合は、｛｝があればどこまでがif文またはelse文の処理かひと目でわかり、相手に考えさせることがなくなるので、必ず｛｝をつけるようにしています。

ネストが深くなると処理が複雑になり、解析が難しくなります。
また、このような場合は、関数名から読み取れる機能と実際の機能にズレができることがあります。
ひとつの関数にいろいろなことをさせずに関数を分けることで、ネストが減り、見やすさの向上につながります。

go to文は、go to “ラベル”と書くことで“ラベル”の位置に処理を飛ばすことができます。
ほとんどの場合、go toを使わずにプログラムを書くことは可能です。
go to文により、無条件で処理が飛ぶので、解析が複雑になり、不具合のもとになる場合があります。
特別な場合以外は、go to文を使わないほうが保守性のために良いと思います。

どんなときでも適用できるというわけではありませんが、異常ケースと正常ケースをわけて、異常処理を先に終わらせることでコードがわかりやすくなる場合があります。 例として、aかつbが1のとき、正常と判断して、cの値に応じてDataを設定して、aまたはbが1以外のときは、異常として、処理を終了するプログラムで説明します。

エラーチェックを切り分けない場合

エラーチェックを切り分ける場合

私の場合、エラーチェックが不足して、意図しないデータで処理してしまい、不適合につながった経験が何度かあります。そのため、不適合を作らないようにするためにもエラーチェックを切り分けるように注意しています。

コードの意図や要約の説明をコメントにします。
その際にソースコードの内容をそのままコメントにせず、コードを補足する内容を書くように注意が必要です。
機能としてまとまっている部分は、複数の処理をまとめてコメントで説明するなど工夫が必要です。
コード説明のコメントで大切なことは、自分や他の人がソースコードを見たときに困らない内容にするように、思いやりを持つことです。

変更履歴をコメントに入れる場合には、/* Add 日付　担当者　変更内容 */や/* del 日付　担当者　変更内容 */という内容にして、誰がいつどのような変更を入れたかわかるようにしています。変更内容には、検索しやすいようにキーワードを入れています。
私は、ファイル管理ツールを使っていますが、コードを見ただけでも変更箇所がわかるように変更箇所のコメントを入れるようにしています。