.NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
Archived MSDN and TechNet Blogs 2/7/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目
※2011.3.30追記 11個目の判断項目を追加しました。 また、「昔はね...」の補足説明を各項目に追加しました。 レガシープログラマ = モダンな言語のおいしい機能をうまく使いこなせていないプログラマ おいらは時々社内システムのコードレビューなんかをやっているのですが、「なんかちょっと前時代的だな〜」とか「ちょっと修正したらC言語でもコンパイルできそうだな〜」って思うことがよくあります。 おいらがレビューする言語は主にC#です。C#やJavaのような比較的モダンな言語のおいしい機能をうまく使いこなせていないプログラマを、ここでは「レガシープログラマ」と呼ぶことにします*1。 そこで、おいらがこれまでに見てきたコードの中から「これはレガシープログラマっぽい」と思った典型的な症例を10個11個挙げてみます。 レガシープログラマの判断項目 使われるローカル変数をすべてメソッドの最初に宣言す
実践Go言語 - golang.jp
Go言語とは、Googleが開発した新しいプログラミング言語です。 当サイトではこの新しい言語についての情報を集約していきます。 このサイトの更新が滞っており、情報が古くなっておりますのでご注意ください。 はじめに Goは新しい言語です。既存の言語からアイデアを取り入れてはいますが、他の言語にはない機能をもっているため、実際に記述されたGoのプログラムは、他の類似した言語とはだいぶ異なるものになります。C++またはJavaプログラムをGo言語へ直接変換しても、あまりうまくは行きません。JavaのプログラムはあくまでJavaで書かれており、Go言語で書かれてはいないからです。一方で、Go側の視点からこの問題を考えると、変換に成功したとしても、全く違うプログラムができてしまうことになります。言い換えると、Go言語を使いこなすには、Go言語の機能や文法を理解することが重要です。おなじく、Go言語
長い関数名、変数名、どこまで許せる？ | スラド デベロッパー
最近久しぶりにWindows関連の案件に関わったのだが、ここ数年UNIX/Linuxばかりを触っていたので結構な違和感があった。特に気になったのが、関数名や変数名などの識別子が長くなる傾向がある点だ。たとえば「GetApplicationConfigurationString」とか、「SaveAllChangeSetToDatabase」とか、確かに分かりやすいのだがタイピングするのに指が絡まるわ！と思う識別子名が多々あった。 そもそもWindows APIには長い関数名、変数名が多く、IDEの補完機能によって長い識別子も入力しやすくなっている、という背景もあるのだろう。しかし、長い識別子名が多いと1行は78文字以内というポリシーを守るのがかなりきつい。長い識別子を許した方が分かりやすいかもしれないが、それでコードが見づらくなるのは個人的にはちょっと避けたいところである。 /.J読者でプロ
サルでもわかる 逆引きデザインパターン 第2章 逆引きカタログ ロジック編 Factory/Factory Method（ファクトリ/ファクトリメソッド）
イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場
「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Tour of Go