ＢＳＴＲ ＶＡＲＩＡＮＴ ＳＡＦＥＡＲＲＡＹ
VBScript ではIDispatchインタフェースを使ってＣＯＭサーバを呼出します。 受け渡すパラメータは、ＶＡＲＩＡＮＴ互換のタイプを使います。 ここではわかりにくいＢＳＴＲ ＶＡＲＩＡＮＴ ＳＡＦＥＡＲＲＡＹを親切に説明。 ＢＳＴＲの使い方 ＢＳＴＲは、クライアントとＣＯＭサーバで文字列のやり取りに使います。 ヘッダファイルの定義は、 typedef OLECHAR *BSTR typedef WCHAR OLECHAR; typedef unsigned short WCHAR; となっています。ようするにWCHAR(unsigned short)のポインタです。最初に文字列の長さが入ります。 次のように文字列でパラメータを受取りたいときに使います。 下の例では、UNICODEをASCII に変換しています。 STDMETHODIMP CBasp21::SendMail(BSTR
きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeviceIoControlのIOCTLコードには何を設定すれば良いの？
URL変更のお知らせ
