« 2004年11月 | メイン | 2005年01月 »
2004年12月29日
長いプロシジャは悪か
よく１つのプロシジャは20行以内だとか、1画面に収まる程度だとか、1枚に印刷できる行数までとか言ったりします。
どれが正しいのか、私には判りません。
というか私にはどれも間違っていると思います。
物理的な長さなどよりもそのプロシジャが「目的を達成するため」に書かれているかそうでないか、の方が行数を気にするより価値があると思うのです。
投稿者 tatsugoro : 18:37 | コメント (0) | トラックバック
2004年12月28日
まずは動かす
よりよいコードにすぐになるわけではありません。
実現方法がわからないのにコードの品質にこだわりすぎてても、物笑いのタネにしかなりません。
まずは、動かしましょう。
そして、その実現方法を足がかりに、いろいろな方法をみつけていきましょう。
いろいろな書き方をするうちに、よりよい状態にたどり着けるかもしれません。
投稿者 tatsugoro : 13:57 | コメント (0) | トラックバック
2004年12月27日
重大な意味をもつ条件式の評価は、処理の中心となるプロシジャで行うべきである。
要件にとって重大な意味をもつ条件式の評価は、処理の中心となるプロシジャで行うと読みやすくなります。処理の中心となるプロシジャとは、Mainメソッド、イベントプロシジャ、外部に公開されているメソッド、外部に公開されているプロパティなどいろいろな場合があるのですが、ここでは、それらに限らず、「要件を実現することを記述している」メソッドをさしています。
こうすることで、その要件を簡潔に表現するプロシジャができあがりますから、要件外の動作をしたときに切り分けやすくなりますし、読みやすくもなります。
サブプロシジャや別クラスのメソッドに条件式を移動する必要を感じたときでも、その条件式が「ユーザの要件の重要な判断を含む」ものであるときは、安易な移動はしないように注意しましょう。
一般的によく行われていることで、クラス分割の基準にもなるでしょう。
クラスなどの責務だけに目を奪われると、重大な条件式が散逸してしまうことがありますので注意が必要です。
投稿者 tatsugoro : 15:30 | コメント (0) | トラックバック
70-219に合格した
70-219 :Designing a Microsoft Windows 2000 Directory Service Infrastructure
に合格した。
あとは、
70-216 :Implementing and Administering a Microsoft Windows 2000 Network Infrastructure
でMCSE(Windows2000)トラックが取れる。
もう一息です。
投稿者 tatsugoro : 12:10 | コメント (0) | トラックバック
2004年12月24日
再利用するなら、再利用時のコストも考慮するべき
コードの再利用にはコストがかかる。
再利用可能な形にすること、告知すること、再利用可能なものが無いか探すこと、再利用するためにそれを学習すること、再利用のためだけのコードを書くこと、共通のプロシジャになったことによるバグが発生すること、仕様の変更があったときテスト対象が広がってしまうこと、ユーザ要件外のドキュメントが発生すること、などなどまだある。
そのコードを再利用可能なものにするほどメリットありますか？
投稿者 tatsugoro : 13:59 | コメント (0) | トラックバック
2004年12月22日
メーリングリストvbdotnet-groupを開設しました
Yahooグループ内にメーリングリスト活動を行うためのvbdotnet-groupを開設しました。ぜひご加入ください。
宇宙仮面様にお許しをいただいて、.NET/C#グループの姉妹メーリングリストとさせていただくことができました。
.NET一般とC#のことは.NET/C#グループへ、VB.NETがからんできて.NET/C#グループでは投稿しづらいものはvbdotnet-groupへお願いします。
投稿者 tatsugoro : 10:05 | コメント (2) | トラックバック
.NET/C# Groupのメンバーサイトになりました
宇宙仮面さま主催のYahoo!グループ .NET/C# グループのメンバーサイトになりました。
私のプライマリ書き込みMLにするつもりです。よろしくおねがいします。
投稿者 tatsugoro : 10:01 | コメント (0) | トラックバック
掲示板設置しました
いまさらながら掲示板を設置しました。気軽に書いてください。
いままではBlogへのコメントをお願いしていたのですが、関連するエントリーが無いとコメントのしようがないですもんね。
投稿者 tatsugoro : 09:58 | コメント (0) | トラックバック
2004年12月21日
テクノロジーと分離せよ
ビジネスロジックから技術に依存するコードをできるだけ排除しておくと、きれいなコードになりやすい。
逆に、ロジックがテクノロジーを要求するものだったときは分離してはいけない。無理に分離すると理解しづらいコードになるので注意が必要。
それを見極めるのがプロの仕事というもんです。
投稿者 tatsugoro : 15:06 | コメント (0) | トラックバック
2004年12月20日
ブラックボックス化
カプセル化せず、ブラックボックス化してしまっていることがある。
内部でなにをやっているのか、外部から隠してしまうというのは正常なクラスのコードだ。普通に存在している。
ただ、コードを隠したいがために、目的や処理が外部からまったく見えなくなったりしていないだろうか。
そうなってしまったクラスは、カプセル化されているのではなく、ブラックボックス化してしまっている、ということにしている。
投稿者 tatsugoro : 15:52 | コメント (0) | トラックバック
ブロックステートメントで不要な分離を避ける
C#にはブロックステートメントというものがあります。
C# 言語の仕様 8.2 ブロック
関数化したいと思ったら、ちょっとだけ、ぐっとこらえて、ブロックステートメントで表現できないか試してみましょう。たった１度しか呼ばれない関数を乱造するより、ぜったいいいです。
「開いた関数」と思えば違和感が減ってきます。
VB.NETにもこの書き方ができてほしいです。
private void Form1_Load(object sender, System.EventArgs e) {
Hasiru("ぐりこ");
Hasiru("ぽっきー");
}
void Hasiru(string Oyatsu) {
int nHashireru = 0;
{
if (Oyatsu == "ぐりこ") {
nHashireru = 300;
} else {
nHashireru = 100;
}
}
Debug.WriteLine(string.Format("{0}m走れます。",nHashireru));
}
投稿者 tatsugoro : 14:49 | コメント (1) | トラックバック
土日の開発者の集まり
土日に開発者があつまる会がありました。
もともとの集まった目的もかなり有意義なものだったけど、それよりも泡盛が入ってからの濃さはほかのお客さんも、店員さんも引くほどのものでした。
やっぱし、「ひざ突き合わせてアルコールがある状態」、こそが「最高レベルのブロードバンド」、「高情報状態」だと確信です。遠くからいらっしゃるかたもいてなかなか集まりにくいのですが、またやりたいですね。
投稿者 tatsugoro : 10:37 | コメント (0) | トラックバック
2004年12月14日
39.2度の熱、嘔吐、ひどい下痢
39.2度の熱、嘔吐、ひどい下痢。
熱はずいぶんさがったけど、下痢と体調不良はつづいてます。
子供が保育園からもらってきたウィルスが原因らしいです。
投稿者 tatsugoro : 00:22 | コメント (0) | トラックバック
2004年12月09日
読みやすさに貢献しているか
人それぞれの考え方でプログラミングするのは好きにすればいいとも思うけど、１つだけきにしてもらいたいことが、そのコードは読みやすさに貢献しているものになっているか、ということ。
構造や、見た目がきれいになったからといって、読みやすいものとは限らない。
同じことを実現するというのに、いろんな書き方ができてしまう。
リファクタリングとは違う、自然言語の文章の推敲と同じ思考が必要だと思う。
投稿者 tatsugoro : 14:44 | コメント (0) | トラックバック
C#にはgotoがある
C#にはgotoがある。
C#プログラマーズリファレンス gotoステートメント
http://www.microsoft.com/japan/msdn/library/ja/csref/html/vclrfTheGotoStatement.asp
それも便利になったのが。
switchの中でgotoを使ってラベル間移動！
http://www.microsoft.com/japan/msdn/library/ja/csref/html/vclrfTheSwitchStatement.asp
switchのなかをgotoしまくってます。
ユーザロジックを記述するときに使えるかもしれない。
MSDNライブラリには
-------------------
通常、goto は switch ステートメントの特定の switch-case ラベルまたは default ラベルに制御を移動するのに使用します。
goto ステートメントは、階層の深い入れ子のループから抜ける際にも便利です。
-------------------
と書いてある。
ちゃんとつかえば便利です！
あ、そうそうVB.NETにもありました、Go Toステートメント。
でも、こちらには
-------------------
GoTo ステートメントを使用するとプログラムは読みにくくなり、保守が困難になります。
-------------------
と書いてあります。
C#では便利、VBではちゃんと使え。
まぁ、あってるけど、VBプログラマ、MSさんに怒ったほうがいいかもね。
残念ながら、どうやら、Select CaseでGo Toは使えないみたい。
投稿者 tatsugoro : 14:02 | コメント (0) | トラックバック
安易なサブルーチン化は、意味不明化になる
まとめられる処理をみつけたからといって、安易にサブルーチンにまとめようとしてはいけない。
それらのコードは、そこにそうかかれているからこそプログラムソースに意味と判りやすさを与えていることがある。
せっかく名前つきのプロパティになっているのに、名前なしの引数にされてしまっては難読化としかいえない。
そういうコードがとても多く存在するので注意しなければ。
投稿者 tatsugoro : 11:39 | コメント (0) | トラックバック
2004年12月08日
コードを読むときモードと、コメントを読むときモード
プログラムソースファイルには、コードとコメントが書かれています。
今は、コメントもコードのうちだというのはおいておいてください。
私はコメントだけを拾い読みすれば全体を把握できるように書いています。
詳しく知りたくなったらコードを読めばよいのです。
コードを読むときモードと、コメントを読むときモードに頭を切り替えて対応です。
VisualStudioのアウトラインに近いかもしれませんが、この方が効率よい作業ができます。
投稿者 tatsugoro : 19:33 | コメント (0) | トラックバック
2004年12月07日
Tech Ed 2005 Yokohamaやるみたいだ
MSさんからTech Ed 2004参加者向けのメールが届いた。
その文面によると、Tech Ed 2005 Yokohamaをやるらしい。
楽しみです。体重変化。
投稿者 tatsugoro : 18:27 | コメント (0) | トラックバック
ローカルな問題をグローバルな問題にしてしまっていないか
ある特定の範囲で判っていれば十分な事柄を、広範囲にまで影響の及ぶ領域にまで拡大して実装してはいないだろうか。
きれいな設計とは、必ずしも全体をひとまとめに統合することではないと思う。
統合をめざすことよりも、思想・発想が一環していることが大事なはずだ。
投稿者 tatsugoro : 14:41 | コメント (0) | トラックバック
2004年12月06日
MCP試験70-217にやっと合格
MCP試験70-217 Implementing and Administering a Microsoft Windows Directory Services Infrastructure
にやっと合格しました。
これのおかげで、遊びも、codeseek.netの更新もおろそかになってました。
この試験はActiveDirectoryの実装と管理についてのどちらかというとITプロと呼ばれる人達向けもので、コーディング主体の仕事をやっている私にとってまったくの畑違いの代物。単語の意味が判らないため問題集を理解して読むことができず、ActiveDirectoryを基礎からやりなおすことになったのでした。
このジャンルの試験では、PCとかコンピュータとか言わずに、クライアントとかメンバサーバーとかって感じで役割を明確に区別した言い回しをしてるのも印象が残ったこと。
一般の人がコンピュータを仕事にしている人達に向けて感じている、なんだかわかんないけどすごいことをしてることだけはわかるぞ感を、実感できました。
投稿者 tatsugoro : 12:23 | コメント (0) | トラックバック
目的の実現を中心としたコードを追加
プログラミング考目的の実現を中心としたコードを追加。
どう書けば、後々読みやすいと言われるコードになるのか。
いろんな書き方をしてたどり着いたことの一つが、「目的の実現を中心としたコード」を書くこと。
逆に言うと、「目的以外の状態になったら、さっさと抜ける」ということ。
リンクも読んでください。