ゲスト さん:

コメントありがとうございます。

>見やすくわかりやすいソースにする為のコツやルール決め等が知りたいです。

一般論としてひと言で答えるのが難しいご質問ですね。。

とはいえ、とりあえず書き出してみました。
僕が意識していることは以下ですね。

・変数の宣言を強制する( Option Explicit )
・変数宣言時にはデータ型を指定する
・プロシージャや変数、定数のネーミングルールを統一する
・全体の流れや個々の行の趣旨を明確にするためコメントを入れる
・構造化プログラミングの作法を守る
・途中改行を必要に応じて入れる
・似た機能のプログラム部品は呼び出し可能なサブルーチンにする
・極力簡素な構造で表現できるように全体を構想する
・コードの複雑さを回避するためにDPRを意識した業務フローになるよう業務全体を見直す( http://www.exvba.com/dpr.php )
・例外は、極力、 On Error ではじまるエラー処理コードではなく条件分岐で処理する
・プログラムの出口は極力ひとつにする( Exit Sub, End, Goto 文を使わない)
・自分のあとにメンテナンスするプログラマーのスキルレベルによっては
・高度に抽象化された手法はあえて用いないようにする
・自動記録で生成されたコードについては無駄な部分を極力省く。

あと、僕は、開発効率と可読性担保のために独自開発した自作のライブラリを使ってプログラミングしています。

まずはそんなところで。

2016/12/16 08:26

小川慶一 さん:

質問者ではありませんが、大変参考になりました。
以下は、本講座を受講した私ができるようになった項目です。
　①②④⑤⑥⑩

まだまだこれからですが、よろしくご指導をお願いします。

①・変数の宣言を強制する( Option Explicit )
②・変数宣言時にはデータ型を指定する
③・プロシージャや変数、定数のネーミングルールを統一する
④・全体の流れや個々の行の趣旨を明確にするためコメントを入れる
⑤・構造化プログラミングの作法を守る
⑥・途中改行を必要に応じて入れる
⑦・似た機能のプログラム部品は呼び出し可能なサブルーチンにする
⑧・極力簡素な構造で表現できるように全体を構想する
⑨・コードの複雑さを回避するためにDPRを意識した業務フローになるよう業務全体を見直す( http://www.exvba.com/dpr.php )
⑩・例外は、極力、 On Error ではじまるエラー処理コードではなく条件分岐で処理する
⑪・プログラムの出口は極力ひとつにする( Exit Sub, End, Goto 文を使わない)
⑫・自分のあとにメンテナンスするプログラマーのスキルレベルによっては
　・高度に抽象化された手法はあえて用いないようにする
⑭・自動記録で生成されたコードについては無駄な部分を極力省く。

2016/12/17 06:00

田中 宏明 さん:

コメントありがとうございます。

以下の2つは「発展編1」本編で扱っています。 http://www.exvba.com/hatten1.php

[03] プロシージャや変数、定数のネーミングルールを統一する
[13] 自動記録で生成されたコードについては無駄な部分を極力省く。

以下では、 Exit Sub のみ、「発展編1」で登場します。あとの2つは使わなければいいだけなので講座では紹介していません。
[11] ・プログラムの出口は極力ひとつにする( Exit Sub, End, Goto 文を使わない)

- - -

以下は「発展編2」本編で扱ってます。 http://www.exvba.com/hatten2.php
「発展編1」でも少しやっていますが、引数つきプロシージャのほうがより高度な部品化です。

[07] 似た機能のプログラム部品は呼び出し可能なサブルーチンにする

- - -

以下は、DPR講座にて。 http://www.exvba.com/dpr.php

[09] コードの複雑さを回避するためにDPRを意識した業務フローになるよう業務全体を見直す

- - -

以下は、各講座のドリルや演習を通じてだんだん身につけていってください。
実務での活用→ドリルや演習→実務での活用→ドリルや演習→ ... というサイクルをくり返しているとどんどん上達するものと思います。

[08] 極力簡素な構造で表現できるように全体を構想する
[12] 自分のあとにメンテナンスするプログラマーのスキルレベルによっては高度に抽象化された手法はあえて用いないようにする

もっとも、上記[08]と[12]はある意味方向性が逆です。
一般的に、高度に抽象化された手法を使ったほうがコードはより簡素な表現にできるからです。

どの程度の抽象化レベルを目指すか？ということについては、以下のブログ記事を参考にしてください。

[質問] 同じ機能を実現するマクロの書き方が複数ある場合、どの書き方が良いか分からなくて迷います。
http://www.exvba.com/blog/?p=4378


>小川慶一 さん:
>
>質問者ではありませんが、大変参考になりました。
>以下は、本講座を受講した私ができるようになった項目です。
>　①②④⑤⑥⑩
>
>まだまだこれからですが、よろしくご指導をお願いします。
>
>①・変数の宣言を強制する( Option Explicit )
>②・変数宣言時にはデータ型を指定する
>③・プロシージャや変数、定数のネーミングルールを統一する
>④・全体の流れや個々の行の趣旨を明確にするためコメントを入れる
>⑤・構造化プログラミングの作法を守る
>⑥・途中改行を必要に応じて入れる
>⑦・似た機能のプログラム部品は呼び出し可能なサブルーチンにする
>⑧・極力簡素な構造で表現できるように全体を構想する
>⑨・コードの複雑さを回避するためにDPRを意識した業務フローになるよう業務全体を見直す( http://www.exvba.com/dpr.php )
>⑩・例外は、極力、 On Error ではじまるエラー処理コードではなく条件分岐で処理する
>⑪・プログラムの出口は極力ひとつにする( Exit Sub, End, Goto 文を使わない)
>⑫・自分のあとにメンテナンスするプログラマーのスキルレベルによっては
>　・高度に抽象化された手法はあえて用いないようにする
>⑭・自動記録で生成されたコードについては無駄な部分を極力省く。

2016/12/17 16:23