わかりやすいファイル構成 への返答
投稿で使用できる特殊コードの説明。(別タブで開きます。)
以下の返答は逆順(新しい順)に並んでいます。
投稿者 けろ-みお ()
投稿日時
2008/9/11 20:06:00
>>5
ただし、プロジェクト分割は、多数のプロジェクトに分割しすぎたり、１ソリューション内に多数のプロジェクトを押し込めてしまうと、Visual Studio のIDEが話にならないくらい重くなってしまいます。（寝耳に水です。特に2005の場合は要注意です）
プロジェクト分割を行う場合、ソリューションの分割単位（ライブラリ化）も検討すると、良いかもしれません。
がんばって下さい。
ただし、プロジェクト分割は、多数のプロジェクトに分割しすぎたり、１ソリューション内に多数のプロジェクトを押し込めてしまうと、Visual Studio のIDEが話にならないくらい重くなってしまいます。（寝耳に水です。特に2005の場合は要注意です）
プロジェクト分割を行う場合、ソリューションの分割単位（ライブラリ化）も検討すると、良いかもしれません。
がんばって下さい。
投稿者 うたひこ ()
投稿日時
2008/9/11 07:19:00
Public Partial Comment
>クラスビュー
知りませんでした。
こういった悩みが出るまで使い込むと、
Editionの違いを再認識させられますね。
他にもマクロとかあったらいいのにとか、
どのエディションだか忘れましたが、
UMLと直結してコーディングできるような
機能があったと思いますが、
ものすごく魅力に感じます。
>プロジェクト分割
「これは他でも使える！」
と思ったものだけプロジェクトを分離していましたが、
そうですね、もうちょっと系統立てて分割できないか検討してみます。
最近まで、PublicとFriendの違いをきっちり理解していなかったのですが、
参考にしているプログラムで、
クラスはFriend（Protected）だけど
インターフェイスはPublicにすることで隠蔽を図っているものがあり、
「なるほど！」と思って真似しつつあるのですが、
クラス間の癒着を示す指標といいますか、
切り離しのうまくいっていない部分も多々あり、
プロジェクト分割の道のりも甘くはなさそうです。
命名については、今までは.Net流を真似してきましたが、
最近はこちら
http://www.objectclub.jp/community/codingstandard/
のVB規約も参考にしています。
>クラスビュー
知りませんでした。
こういった悩みが出るまで使い込むと、
Editionの違いを再認識させられますね。
他にもマクロとかあったらいいのにとか、
どのエディションだか忘れましたが、
UMLと直結してコーディングできるような
機能があったと思いますが、
ものすごく魅力に感じます。
>プロジェクト分割
「これは他でも使える！」
と思ったものだけプロジェクトを分離していましたが、
そうですね、もうちょっと系統立てて分割できないか検討してみます。
最近まで、PublicとFriendの違いをきっちり理解していなかったのですが、
参考にしているプログラムで、
クラスはFriend（Protected）だけど
インターフェイスはPublicにすることで隠蔽を図っているものがあり、
「なるほど！」と思って真似しつつあるのですが、
クラス間の癒着を示す指標といいますか、
切り離しのうまくいっていない部分も多々あり、
プロジェクト分割の道のりも甘くはなさそうです。
命名については、今までは.Net流を真似してきましたが、
最近はこちら
http://www.objectclub.jp/community/codingstandard/
のVB規約も参考にしています。
投稿者 うたひこ ()
投稿日時
2008/9/11 07:16:00
みなさん、色々とアイディアをご教授いただきありがとうございます。
バージョン記述を忘れてしまい申し訳ありません、
2005のexpressです。
>コードスニペット
vbを始めたての頃、いじくってみたことはあるのですが、
フォルダ階層が深くて、望んだものがあるのかどうか
確認する時間がもったいないと思い、
ほとんど使っておりませんでした。
調べてみたところ、
SnippetEditorというものを発見したので、
使い方を研究してみたいと思います。
また、VBのインストールフォルダの中に、
Zipで圧縮された、VBファイルの雛形を発見しました。
この中のXMLとファイルを書き換えて追加すれば、
多分、ファイル追加操作の際に便利になるのではないかと
画策しています。
>XMLコメント
これは前々から実践していました。
しかし、MSDNの仕様を見ると、もっと色々なXMLタグで
彩り豊かなコメントが記述できるようなのですが、
VBエディタ側ではそこまでちゃんと対応してはいないみたいなので、
なんだか中途半端な書き方になっています。
Hotナントカという仕様書作成ソフトでは
このコメントを用いて仕様書を作成する機能もあるようですが、
皆様はどの程度までこの機能を使いこなしていらっしゃるのでしょうか？どの程度までコメントを埋めますか？
例えば、それほど説明する必要もない、
Get/Setのプロパティが他にあるPrivate変数に対して、
<summary><remarks>を両方きっちり記述しても
なんだか長ったらしい気がしてならないのですが…。
バージョン記述を忘れてしまい申し訳ありません、
2005のexpressです。
>コードスニペット
vbを始めたての頃、いじくってみたことはあるのですが、
フォルダ階層が深くて、望んだものがあるのかどうか
確認する時間がもったいないと思い、
ほとんど使っておりませんでした。
調べてみたところ、
SnippetEditorというものを発見したので、
使い方を研究してみたいと思います。
また、VBのインストールフォルダの中に、
Zipで圧縮された、VBファイルの雛形を発見しました。
この中のXMLとファイルを書き換えて追加すれば、
多分、ファイル追加操作の際に便利になるのではないかと
画策しています。
>XMLコメント
これは前々から実践していました。
しかし、MSDNの仕様を見ると、もっと色々なXMLタグで
彩り豊かなコメントが記述できるようなのですが、
VBエディタ側ではそこまでちゃんと対応してはいないみたいなので、
なんだか中途半端な書き方になっています。
Hotナントカという仕様書作成ソフトでは
このコメントを用いて仕様書を作成する機能もあるようですが、
皆様はどの程度までこの機能を使いこなしていらっしゃるのでしょうか？どの程度までコメントを埋めますか？
例えば、それほど説明する必要もない、
Get/Setのプロパティが他にあるPrivate変数に対して、
<summary><remarks>を両方きっちり記述しても
なんだか長ったらしい気がしてならないのですが…。
投稿者 るきお ()
投稿日時
2008/9/11 06:10:00
プロジェクト自体を分割するというのはどうでしょうか？
規模が大きなシステムでは複数のプロジェクトを作成してソリューションレベルで統合するという手法が一般的です。
プロジェクトの分け方は業務レベルではサブシステムごとに分けることが多いですし、アーキテクチャの観点からはプレゼンテーション層・ビジネスロジック層・データアクセス層などに分けるスタンスが一般的なようです。
ユーティリティ系・フレームワーク系のロジックも巨大になるのであればやはりサブシステムごとに区切って分けていいと思います。
このように分けておくとプロジェクト内のファイル数は減るので見つけやすさは向上します。
ソースコードレベルでは１ファイル１クラスとか、XMLコメントをつけるとか普通(?)の対策以外は私は特にとっていません。
あ、あと、プロジェクト内にフォルダを追加できるので、ファイルをフォルダに分けると整理できます。これはやってます。
規模が大きなシステムでは複数のプロジェクトを作成してソリューションレベルで統合するという手法が一般的です。
プロジェクトの分け方は業務レベルではサブシステムごとに分けることが多いですし、アーキテクチャの観点からはプレゼンテーション層・ビジネスロジック層・データアクセス層などに分けるスタンスが一般的なようです。
ユーティリティ系・フレームワーク系のロジックも巨大になるのであればやはりサブシステムごとに区切って分けていいと思います。
このように分けておくとプロジェクト内のファイル数は減るので見つけやすさは向上します。
ソースコードレベルでは１ファイル１クラスとか、XMLコメントをつけるとか普通(?)の対策以外は私は特にとっていません。
あ、あと、プロジェクト内にフォルダを追加できるので、ファイルをフォルダに分けると整理できます。これはやってます。
投稿者 るしぇ ()
投稿日時
2008/9/10 20:40:00
クラスビューを使ってツリー構造で管理するので、ソース上は何もしないです。
関数名を分かり易くしたり、１つの関数を長くしないように気をつけたり
くらいですかねぇ。
ただ、VB2005 Express Edition だけ何故か実装されていません。
[Visual Basic 中学校 > 初級講座 > 第４０回 開発環境は飾りではない]
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard40.htm
関数名を分かり易くしたり、１つの関数を長くしないように気をつけたり
くらいですかねぇ。
ただ、VB2005 Express Edition だけ何故か実装されていません。
[Visual Basic 中学校 > 初級講座 > 第４０回 開発環境は飾りではない]
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard40.htm
投稿者 けろ-みお ()
投稿日時
2008/9/10 19:15:00
私も過去、同じことで悩んだことがあるので、お気持ちは良くわかります。
もし、使用されているVisual Studio のバージョンが2005以降で、.NET Framework 2.0 以降であれば、Partial Class を使って、1クラス = 複数ファイルとして管理することで、１ソースファイル内にたくさんのステップ（行数）を書かないようにするだけでも、だいぶ助かった経験はあります。
後は、ヘッダですが、Visual Studio 2005以降を使っているのであれば、各メソッド、イベント、プロパティ、フィールドを宣言した前に、シングルクォートを３つ「'''」入力すると、綺麗なコメントが入力できるエリアが表示されますので、それを活用するというのも手です。
今回の趣旨からずれますが、
メンバ変数
プロパティ
イベント及びそれを発生させるメソッド
コンストラクタ、デストラクタ、ファクトリーメソッド
メソッド
という定義順番が予め決まっているのであれば、「コードスニペット」という雛形を作成することで入力の簡略化と生産性をUPすることはできます。
（しかし、今回の場合は既に開発済みのものなので、コードスニペットを導入しても無意味になりますが・・・）
#region の区切りですが、下記のようにネストして使うこともできます。
Public Class Class1
#Region "フィールド"
#Region "内部処理用フィールド"
Private _field1 As String
Private _field2 As String
#End Region
#Region "年月日フィールド"
Private _year As String
Private _month As String
Private _day As String
#End Region
#End Region
End Class
こうすることで少しだけソースコードを見やすくしたことはあります。
この手の話はいろんな手法があるので、他の方のご意見も聞いてみたいところです。
ご参考になれば幸いです。
もし、使用されているVisual Studio のバージョンが2005以降で、.NET Framework 2.0 以降であれば、Partial Class を使って、1クラス = 複数ファイルとして管理することで、１ソースファイル内にたくさんのステップ（行数）を書かないようにするだけでも、だいぶ助かった経験はあります。
後は、ヘッダですが、Visual Studio 2005以降を使っているのであれば、各メソッド、イベント、プロパティ、フィールドを宣言した前に、シングルクォートを３つ「'''」入力すると、綺麗なコメントが入力できるエリアが表示されますので、それを活用するというのも手です。
今回の趣旨からずれますが、
メンバ変数
プロパティ
イベント及びそれを発生させるメソッド
コンストラクタ、デストラクタ、ファクトリーメソッド
メソッド
という定義順番が予め決まっているのであれば、「コードスニペット」という雛形を作成することで入力の簡略化と生産性をUPすることはできます。
（しかし、今回の場合は既に開発済みのものなので、コードスニペットを導入しても無意味になりますが・・・）
#region の区切りですが、下記のようにネストして使うこともできます。
Public Class Class1
#Region "フィールド"
#Region "内部処理用フィールド"
Private _field1 As String
Private _field2 As String
#End Region
#Region "年月日フィールド"
Private _year As String
Private _month As String
Private _day As String
#End Region
#End Region
End Class
こうすることで少しだけソースコードを見やすくしたことはあります。
この手の話はいろんな手法があるので、他の方のご意見も聞いてみたいところです。
ご参考になれば幸いです。
投稿者 うたひこ ()
投稿日時
2008/9/10 06:57:00
こんにちは。
（三倍は何かの心境の変化だと受け止めます。）
ゴタゴタいたしましたが、今はこちらに書き込ませていただくのが最善かなと思い、僭越ながら質問いたします（そう思った経緯についての説明は、今はご容赦下さい。）。
開発物のプロジェクト内のソースファイルが多くなり、開発のスピードが落ちて困っています。
スパゲッティソースではないのですが、自分の探したいコードがどこにあるか見つけるのに無駄な時間を浪費しているのです。
ぱっと見で探したい物がどこにあるのかがわかるように、リファクタリングをしている最中なのですが、イマイチ見やすくないのです。
今までは、
メンバ変数
プロパティ
イベント及びそれを発生させるメソッド
コンストラクタ、デストラクタ、ファクトリーメソッド
メソッド
の順番に、
'メンバ*********
のような区切りコメントをつけて記述していましたが、その区切りさえもコードに埋もれ、とてもみづらいコードになってしまっていました。
見直しの例なのですが、
まずファイルの主要な内容の種類が
１、クラス
２、↑のインターフェイス
３、↑のコレクションクラス
４、↑のインターフェイス
となっています。
１の内容はほぼ全部２で定義されているので、１の中の２の実装部分は
#region"implements_〇〇"
で括ることを試みました。
これは割とナイスな感じでした。
そこに含まれないのは、プライベートなメソッドとメンバ変数とコンストラクタくらいです。
他にもヘッダをつけるなど、見やすくするための工夫を、先人達のサンプル等見ながら考えています。
皆様はどのような工夫をされているのでしょうか？
お聞かせ下さい。よろしくお願いします。
（三倍は何かの心境の変化だと受け止めます。）
ゴタゴタいたしましたが、今はこちらに書き込ませていただくのが最善かなと思い、僭越ながら質問いたします（そう思った経緯についての説明は、今はご容赦下さい。）。
開発物のプロジェクト内のソースファイルが多くなり、開発のスピードが落ちて困っています。
スパゲッティソースではないのですが、自分の探したいコードがどこにあるか見つけるのに無駄な時間を浪費しているのです。
ぱっと見で探したい物がどこにあるのかがわかるように、リファクタリングをしている最中なのですが、イマイチ見やすくないのです。
今までは、
メンバ変数
プロパティ
イベント及びそれを発生させるメソッド
コンストラクタ、デストラクタ、ファクトリーメソッド
メソッド
の順番に、
'メンバ*********
のような区切りコメントをつけて記述していましたが、その区切りさえもコードに埋もれ、とてもみづらいコードになってしまっていました。
見直しの例なのですが、
まずファイルの主要な内容の種類が
１、クラス
２、↑のインターフェイス
３、↑のコレクションクラス
４、↑のインターフェイス
となっています。
１の内容はほぼ全部２で定義されているので、１の中の２の実装部分は
#region"implements_〇〇"
で括ることを試みました。
これは割とナイスな感じでした。
そこに含まれないのは、プライベートなメソッドとメンバ変数とコンストラクタくらいです。
他にもヘッダをつけるなど、見やすくするための工夫を、先人達のサンプル等見ながら考えています。
皆様はどのような工夫をされているのでしょうか？
お聞かせ下さい。よろしくお願いします。
ありがとうございます。
ソリューションの分割というのは考えたことがありませんでした。
ただ、安易に試みると色々と問題が起こりそうにも思うので、検証し、計画を立ててみようと思います。
（解決にするのにはまだ早い気がするので、やめておきます。）