WebFamil 近年プログラミングに携わる人が増え数多くの学び方によってプログラミングを習得しています。
プログラミングで大切なのは「正しく動作すること」であり、結果が正しければ過程（プログラミング）は何でもよいという考え方もあります。
ただし作って一生直さないシステムは聞いたことがありません。
自分にしても別の人にしても一度作ったシステムを改修したり機能追加したりせっかく作ったシステムを活用するためには手をかける必要があります。
まっさらな状態からのプログラミングは割と簡単です。何もないので・・一度作成されたプログラムに手を入れるのは大変です。
ここではある程度プログラミング経験がある方向けの質の良いプログラミング方法について記載致しますので是非お読みください！
プログラミングとは、、、
プログラミングとは、「コンピューターが処理を行うための命令を記載すること」です。
コンピューターが読み取れるように記載すれば綺麗に記載してもバラバラに記載してもプログラムは正しく動作します。
コンピューターはプログラムさえ書いてあればその通り実行します。しかしプログラミングをするのは人間です。読みにくいプログラミングは改修にくく、バグを埋め込みやすいです。
そのためプログラミングの定義を一段階上げて、「コンピューターが処理を行うための命令を誰が見てもわかりやすく記載すること」と意識することが大切です。
わかりやすいプログラミングの条件
では良いプログラミングとはどういうことなのか、誰がみてもわかりやすいプログラミングとはどういうことなのかを説明します。
特に単発もののプログラムではなく、複数のプログラムから構成されるシステムをターゲットとします。
ここでいう「良い」は個人の所感なので人によってバラつきはあるとは思いますが、そんなにずれている発想ではない！と思っています。。。
インデントをつけよう！
これはプログラミングの基本中の基本！インデントがないプログラミングはほんと読みづらいです。ソースを見た瞬間ゲンナリするくらいです。。。
特にIF文やLOOP文などはインデントが命と思っています。
例を挙げてみます。（言語は何でもいいですが例はVBAです）
インデントがないパターン
if hoge1 = true then
if hoge2 = hoge3 then
print ‘a’
end if
else
for i = 0 to i = 6
print ‘b’
loop
end if
たったこれだけの例を書いただけでモヤモヤがとまりません。。
では、インデントをつけてみます。
インデントがあるパターン
if hoge1 = true then
if hoge2 = hoge3 then
print ‘a’
end if
else
for i = 1 to i = 6
print ‘b’
next i
end if
スッキリしました！上記のようにインデントをつけるだけでif文の開始と終了が一目でわかりやすくなります。
ちなみに後からインデントをつけるのは大変です！最初のコーディング時にしっかりインデントをつけるクセを身につけましょう。
コメントをつけよう！
では続いてコメントです。プログラミングは書いているとき頭の中で整理されているためコメントがなくても全く問題ありません。
ただし2週間くらい？時間をおいて自分のソースをみると？？？が止まりません。「あれ？これなんだっけ？」「なんでこんなことしてるんだ？」という2週間前の自分に聞きたいくらい。。。
また処理の内容を確認するのにいちいちソースを全部見ないと処理内容がわからず作業効率が落ちます。
ファイルの最初にコメント
プログラムファイルは1ファイルではなく数多くのファイルから構成されることが多いです。
そのためファイルの先頭にこのファイルに記載するのはこのような処理ですよというコメントがあるだけでOKです。
/*********
* 〇〇画面 DBアクセス処理
*********/
部品（メソッド）ごとにコメント
プログラムはオブジェクト志向の部品化を意識することで多くの部品（メソッド）を作成します。
その部品の機能概要、引数、戻り値は書きましょう。
プログラムの改修が入ったら機能概要や引数、戻り値なども整合性をとりましょう。
そうすることで「この部品はなんだっけ」というときにコメントを読むと概要から機能を思い出すというわけです。
/********************
*機能概要：セルの情報を取得する
*引数：行,列
*戻り値：値
********************/
function GetCellValue(iRow,iCol) as strvalue (
strvalue = Thisworkbook.Activesheet.cells(iRow,iCol).value
)
コメントがつくと一気にプログラミングになりますよね！
行ごとにコメント
プログラミングをするときは1行ごとにコメントを書きましょう！というとコメントが多すぎて見にくくなることがあります。
たまにコメントが丁寧すぎて全行コメント付きというのを見たことがりますが、ステップ数（ファイル全体の行数）が単純に2倍になります！
複雑な処理を開始する場合やキーポイントとなる処理にはコメントがあった方がわかりやすいです。
インデントの例でコメントを記載してみます。
‘分岐処理開始 hogeがtrueの場合、hoge2とhoge3を比較
if hoge1 = true then
if hoge2 = hoge3 then
print ‘a’
end if
else
‘1～5行目までbを出力
for i = 1 to i = 6
print ‘b’
next i
end if
このくらいのコメント量が個人的には好きですね。
コメントでありがちなのは、プログラム改修時にコメント修正が間に合わずコメント通りを真に受けたらエラーになるというケースです。
プログラム=コメントなので、必ず両方合わせて直すようにしましょう。コメントに騙されることって意外と多いです。。。
設計書通りにプログラミングしよう！
プログラミングをするときは設計書ありき！それを前提に話をします。設計書というのはプログラムの処理機能や詳細を記載したもの。これがないとお客様とのコミュニケーションをとるのも大変です。
システム構築は要件定義や外部設計、内部設計とまずは設計を先に行います。そこでお客様と要件を整理したり他システムや自システム内の整合性をとっていきます。
プログラミングをしているとたまに神が降りてきて色んな発想がでてきます。プログラミングハイというのでしょうか。。。
1機能の1処理を設計書から逸脱すると、結合テストでバグになりやすいです！
ただし！設計書が必ず合っているというわけではありません、設計書に必ずすべて記載してあるというわけではありません。
疑問に思ったり不備を感じたら必ず設計者に確認しましょう。自分で設計したのであれば他の設計書との整合性を確認しましょう。
「設計書に書いてあるのでその通りにプログラミングをしました」「設計書の記載がないのでプログラミングだけしました」というのはシステムの歪となりやすいので気を付けて、「ここは〇〇だから××ですよね？」というコミュニケーションひとつとるだけでバグを防ぐことができます。
処理を共通化しましょう！
プログラムはだらだら書くと冗長的なプログラミングになりやすいです。そのため共通化（部品化）できるものはしっかり共通化をすることでコンパクトなプログラミングができます。
また改修が発生した時も部品を直すことで漏れなく対応でき、直し漏れというトホホな障害を減らすこともできます。
変数名は適切な名称にしましょう！
プログラミングにおける変数とは「箱」のようなものです。色んな値が入ります。
ただし「箱」にもしっかり用途を明示するような名前をつけましょう。
なんのための「箱」なのかをはっきりさせることで不要な使いまわしをさけることができます。また「箱」の名前を見ただけでその「箱」がどこで使われているのかがすぐに見つけることができます
たまに見かけますが「tmp1」とか「a1」とか、、、もはや何の変数なのかソースを見ないとわかりません。
よくある変数の命名規約では型名＋変数の用途です。
インデントの例では「iRow」という変数を利用しています。
これはInteger型＋行（Row）という意味です。これで数値型が入る行数ということが一目でわかります。
定数を利用する
プログラミングの中には固定値を利用するものが出てきます。固定値というのは値が変わらないので固定値なわけです。
そのため一度定義するとなかなか変更することはないにしても、前提条件が変わることで値を変更する場合があります。
ソース内の直接値を書くことを「べた書き」とか「ハードコーディング」とか呼びますが、基本的に「べた書き」はNGです。
定数は定数ファイルにまとめて記載するか、ファイルの最上部にまとめて書きましょう。
そして必ず何の定数なのかコメントを記載します。
「べた書き」はNGですが、プログラミング中の定数も同じくらいNGです。
質の良いプログラミングをするには？！
正直綺麗にプログラミングしても汚くプログラミングしても処理が同じならプログラムの処理結果は同じです。特にお客様には何にも影響ありません。
それなら書き方なんて何でもいいか！といえばそうは思いません。
綺麗なソースをみると「この人は仕事が丁寧な人かな」とか勝手に信頼感を増します。（私はそうです。。。）
反対に雑なソースをみると2回目の仕事は悩みます。
では綺麗なコーディングをするにはどうすればいいのかを挙げます。
コードレビューを受ける
やはり一番いいのは自分以外の人にソースをみてもらうことです。一人ではなく色んな人に見てもらって色んな意見を聞くことです。
周りに同じようなプログラマーがいる人はぜひ相互コードレビューをしてみましょう。
上長やSEにコードレビューをお願いする場合は本ブログに記載のところを対応するのは最低限かと思います。過去にはインデントがついていないコードレビューは2秒で終了しました。コードレビューにならないと・・・
他のソースを見る
上と似ていますが、他の人のソースを見ることは勉強になります。自分が読みやすいと思うか、なぜ読みやすいのかを意識することで、結局どういうソースが良いのかを学ぶことができます。
プログラミングは十人十色！直感的に処理が想像できるかどうかがポイントかと思います。
自分のソースを時間おいてからセルフレビューする
自分のソースが見やすいのか、それを確認するには自分でソースを見るしかありません。ただしプログラミング直後はダメです！
頭の中に処理が残っているので何となく処理がわかります。自分でプログラミングしたなら当然ですよね。
では2週間くらい時間をおいてからソースを見ましょう。
たぶん笑っちゃうくらいわからないかもしれません。私はそういう経験があります。
自分だけはどれだけ時間が経ってもわかるようにしておきたいですね。
まとめ
今回は「わかりやすいプログラミング」に必要なことを挙げました。
おさらいすると、、、
- インデントをつけよう！
- コメントをつけよう！
- 設計書通りにプログラミングしよう！
- 処理を共通化しましょう！
- 変数名は適切な名称にしましょう！
- 定数を利用する
プログラムに書き方なんて関係ない！そんなこと言わずに意識してプログラミングするだけで誰でも対応できます。
そして一度対応できると他の人のソースが気になります！
字が汚くても読めればいい→字は綺麗な方がいい
部屋は汚くても住めればいい→部屋は綺麗な方がいい
ソースは汚くても動けばいい→ソースは綺麗な方がいい
というイメージです。
そういう細かいところを丁寧に仕事する人ほど信用できるかなとおもいますので是非実践してみてください。
[insert id=1043]