VBAを始めて1年ほどになります。
プログラム（マクロ？）を本格的に勉強したのは、これが初めてです。
いろいろ作ってきて毎度共通の悩みがあります。
ソースなんですが、なんというか、「美しくない」のです。
作っている時は良いのですが、数日経って修正が必要になった時などに、ソースを見るのが嫌で嫌でたまりません。
変数が少ないのかと変数だらけにしたら、それはそれで何をやっているか分からなくなってきましたし、変数を日本語にすれば分かりやすいかと試してみれば、日本語ってどうも黒い四角にしか見えなくてパッと見が分かりづらかったりと、どうもうまくいきません。
プログラムは人が読むことを前提に見やすく書くべしと聞きますが、自分でも見難いソースしか書けない自分が嫌になってきます(^_^;
プロの方はいったいどういうところに気をつけて、読みやすいソースを書かれているのでしょうか？
美しいソースとはどういうものなんでしょうか？
一般論、個人的なこだわり、いろいろあるとは思いますが、よろしくお願いいたします。
投稿日時 - 2009-11-20 11:50:58
この問題はプログラムを書く人間には永遠の課題だと思います。
２節に分けてみます。
☆一般論
・コメントを”適度”にしっかり書く
・サブルーチン（関数とかメソッドとか）を”適度”に使用する
・容易な変数名は”なるべく”使用しない
・スパゲティコードにはしない
・命名規則を”なるべく”遵守する
等々ですかね。
曖昧な部分”適度”や”なるべく”の部分は経験です。
例えば・・・
変数名でi,t,x,y,zは、慣例的にintegerを示している場合が多いです。
特にx,y,z等は座標を示したり、多次元配列を示す場合があります。
また、ColやRow等も慣例的に特定のオブジェクトを示している場合があります。
他の人も書いてますがgoto文はスパゲティコードの代名詞であり、嫌われる傾向にあります。
VBAの場合on error goto文くらいでしょうか許容されるのは。
ただgotoを使わなければイイという訳でもありません。
構造化プログラミングも多重継承しだすとわけわからなくなったり、グロスコープが適切ではなかったりと色々あります。
これらに関してはgoogle先生が詳しいです。
http://ja.wikipedia.org/wiki/スパゲティプログラム
☆VBAに関して
VBAと言うことで、一番使われるExcelやAccessだと想定します。
VBAはVB6以前までの言語構造を踏襲しています。
＃VisualBasic for Applicationの略ですし^^
VB自体あまり美しく書ける言語だとはあまり思えません。
職業プログラマーでもVB6以前ではあまり使用する人が少ないですが、、コツとしてはクラスモジュールを使用するとイイかと思います。
継承などはできませんが部品化するという用途には使えます。
VBAのクラスモジュールの参考サイト
http://codezine.jp/article/detail/499
http://www.excellenceweb.net/vba/class/what_vba_class.html
☆結論
私としては経験でしかないと思います。
職業プログラマーとしては１０年、学生時代の趣味でやっていた頃も含めれば１５年以上になりますが、未だに満足していません。
がんばってください^^;
投稿日時 - 2009-11-24 17:42:54
お礼
なるほど。プロの方でも追い求め続けているものなわけですから、僕程度のレベルの人間は焦らずに地味にがんばるしかなさそうですね。
スパゲティコードというのを初めて聞いたのですが、調べてみると僕が書いたソースはまさにそれでした。
知ってはいましたが見て見ぬふりしていたのがクラスモジュールでした(^_^;
継承とかクラスという言葉すら理解していないのですが、商品化の用途にも使えるとまで聞いてしまっては勉強しないわけにはいきません。
教えていただいたサイトを読んで、じっくり勉強していきたいと思います。
ご回答ありがとうございました。
投稿日時 - 2009-12-08 11:14:37
1人が「このQ&Aが役に立った」と投票しています
ベストアンサー以外の回答（9件中 1～5件目)
>>9に追記です。
命名規則ですがVBAの参考例を以下に書いておきます。
・サブルーチン名など
' intHogeをHogeHogeに設定する
Sub SetHogeHoge(intHoge as Integer)
' HogeHogeを取得する
Function GetHogeHoge() As Integer
' HogeHogeを実行する
Sub HogeHoge()
・変数名など
Dim i as Integer, t as Integer ' ループカウンター等
Dim objFS as Object ' ファイルストリームオブジェクト
Dim objCol as Column ' カラムオブジェクト
Dim intTopCell as Integer ' セルの一番上を示す数値
Dim strTableName as String ' テーブル名
Dim strSheetName as String ' シート名
Dim strUserNames(0 to 5) ' ユーザ名配列
投稿日時 - 2009-11-24 17:59:58
お礼
分かりやすい例を教えていただいてありがとうございます。
こういうのを見せていただけると、本当に助かります。
自然にこういう形に書いていけるように慣れていきたいと思います。
ありがとうございました。
投稿日時 - 2009-12-08 11:15:19
>No.7
Goto 原則禁止
開発言語が、VBAで
むしろ今まで GOTO を使用しておらず、
初級レベルから中級レベルにあがろうともがいている
のであれば使ってみる事をお勧めします。
VBA は JAVA のように、GOTOの代わりとなる
Exception や Throw が充実している訳では無いです
そんな言語で
たとえば、今まで GOTO を使用してはいけないと言われ
flgNG = False
Do
If Then
Else
flgNG = True
End If
If flgNG = False And Then
Else
flgNG = True
End If
If flgNG = False And Then
Else
flgNG = True
End If
Loop While (flgNG)
こんな書き方をしているとしたら、そちらの方が
GOTO を記述するより、よっぽど問題です
これ、やってる事は、GOTO を可読性悪く書いてるだけ
可読性が悪くなるという理由で GOTOを使わない事に矛盾
してますよね
完成したソースを見て、GOTOを使えばよりスマートに
記述できる部分をじっくり見直します
その部分を GOTO に直すのではなく、別関数にする事
を第一に考えて見直して見てください
あとは、慣れです
投稿日時 - 2009-11-24 11:40:52
お礼
別関数を作るということに慣れてしまったせいか、Gotoはかなり気を遣わないといけないので、どうも使いづらくなってしまいました。
僕の場合は適度に使うというよりも、最小限にとどめないとそれこそ読めなくなりそうなので、おっしゃるとおり別関数にすることを考えていきたいと思います。
ご回答ありがとうございました。
投稿日時 - 2009-12-08 11:13:35
必要なことはすでに書かれているのでVBAに特化したもので。
あと、ソースを晒せばもっと良い提案ができると思いますよ。
・Option Explicit をマクロ最上段に書く
変数の宣言を強制するステートメントです。
変数の宣言を強制することで、入力ミスを防ぐことができます。デバッグも楽になります。
・変数の名前付けルールを決めて宣言する
例えばですが・・・
ユーザーが独自に作ったことを明示する: my
用途を表す名称: Flag
データ型: Integer
の場合は
Dim myFlag As Integer
と宣言すると整数型以外の使い方ができなくなるためデバックしやすくなると思います。
バリアント型は極力使わないほうが良いでしょう。
・インデントの対応
If 文などで、If文が影響する範囲のコードを字下げすることで、コードの単位がわかりやすくなると思います。
エディタのほうが勝手にやってくれるはずですが・・・
・コードを書く前にコメントで「何の目的で何をやって何を得るか」を書く
どこから呼び出されるかとか、具体的なデータイメージも書いておくと、後でよくわからなくなって一から書くときも調べるのが楽です。
・Goto 原則禁止
便利なことは多いですが、特にループの用途で Goto を使わないほうが可読性が高まります。
・同じ処理、似た処理は Sub や Function でまとめる
VBA は高速性より簡潔性を求める書き方のほうが良いです。
投稿日時 - 2009-11-22 07:21:08
お礼
名前付けのルールはいつも頭を悩ませるところでした。
長すぎても使いづらいし、短すぎても分かりにくいですし。
示していただいて例は大変わかりやすかったです。
自分でつけるのもそうですが、人がどういう風につけているのかが分かったので助かりました。
今まで人が書いたソースを読んでいても、変数なのか関数なのか自分の知らないメソッドやステートメントなのかの区別がつきにくかったもので・・・。
ご回答ありがとうございました。
投稿日時 - 2009-11-23 17:59:06
自分で個人的な工夫を凝らしてもうまくなることはないと思います。
うまくなるコツは、他人の書いたコードを大量に読んで解析することかなと思います。
下手な人のコードを読んでもダメなので、
短いコードではなく、ある程度の規模のソフトの一部を読むのが良いと思います。オープンソースのコードをネットから拾ってきてはどうでしょうか。
うまいコードほど、誰が読んでも理解でき、なおかつ仕様変更に強い仕組みが色々と施されています。
コード上の工夫は過去の人々がやり尽くしているので、自分で編み出そうとはしないことです。まずは真似ることです。
ある程度の量を読みなれると、下手なコードを見た瞬間に違和感がおこるようになります。
今の時点の自分の感覚でわかりやすいかどうかは判定しないことですね。
何度も書きますが、たくさん書くよりもたくさん読んだ人の方がうまくなります。
オープンソースのコードで過去のバージョンも手に入れば、比較して、何がまずくてどう変えたか追跡してみてください。
ちなみにプログラムで変数を日本語というのはあり得ません。
投稿日時 - 2009-11-21 22:19:43
お礼
書くよりも読むというのは目からウロコです。
自分のソースに取り入れるために読むことはあっても、綺麗に書くための分析で読んだことはありませんでした。
どういうのが上手いのか分からないので、なんとなくでも綺麗だなと感じるソースを探していこうと思います。
ご回答ありがとうございました。
投稿日時 - 2009-11-23 17:53:44
それは最初でちゃんとした処理の流れを決めず、
行き当たりばったりでコーディングしているからです。
あ、ここでは判断にフラグをつけよう、
変数は、myFlagにして、っと。。
おっと、Ｅ列とＦ列にこの項目を入れておいた方がコードが書きやすいな、
ということで、コードを加筆・修正したり、、、
こんなことをやってるといくら変数を分かり易いものにしようが、コメント付けよううが、コードは見栄えのよいものにはなりません。
コードを書く前の段階に時間を掛けるのです。
そこに時間を掛けた分、コードは書きやすくなるし、また分かり易く、可読性の高いものになります。
適当な設計で闇雲にコードを書き出しては質問者のようになってしまいます。
次からは時間が掛かるかもしれませんが、コードを書く前に、仕様書、フローチャートを書いてみたらどうでしょう。
格段に違いが出ると思います。
以上です。
投稿日時 - 2009-11-21 11:28:16
お礼
確かに！
加筆はよくやります(^_^;
最初に処理の流れを決めてはいるんですが、実力不足のせいか足りなかったりするんですね。
作ってる途中で「こういう機能もほしい」と思うこともあるので、最初の計画段階でもう少し掘り下げていく必要があると思いました。
仕様書などは書いたことがないので勉強してみます。
ご回答ありがとうございました。
投稿日時 - 2009-11-23 17:51:07
