ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
ソースコードの品質向上のための効果的で効率的なコードレビュー
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
プログラミングが速く組めるようになる初歩的な3つの心掛け - 遥か彼方の彼方から
プログラム雑用兼プログラマーとしてアルバイトしていた頃のこと。僕の最初の悩みは、どうすればもっと速くプログラミングできるか、でした。訳あって3時間ほどしかバイト時間を確保できなかったうえ、雑用もしていたので、気付くとほとんどコードを書かずに一日が終わるなんてこともよくりました。急がなくてもいいとは言われてはいたものの、プログラミング能力が低くて、要領も悪い僕としては、せめて時間内に終わらせられる程度にはプログラミングが速くなる必要があったのです。とはいえ、すぐにプログラミングが上手くなることなんて出来無い。だからせめて、プログラムで詰っている時間を減らせさえすれば、今よりもよくなるんじゃないか、とそう考えるようにしました。そう意識してからの作業は徐々に速くなり、最終的になんとか仕事についていけるようになっていたかなと思います。ということで、前置きが長くなりましたが「プログラミングが速く組め
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
ひげぽん OSとか作っちゃうかMona- - ハッカー養成塾:ハッカーへの遠回り
オープンソースマガジン2007年1月号に向けて書いた記事の元の原稿です。 前回のアルファギーク舘野君から、バトンを渡されたひげぽんです。 Mona OSというオープンソースOSを開発しています。 僕はハッカーと呼ばれるには実力不足ですが、知り合いのスゴ腕ハッカーに少しでも追いつこうと日々実践していることをいくつか紹介します。 ハッカーに学ぶ オンラインでもオフラインでも構いません、自分よりも優れているハッカーを探してお手本とすることから始めましょう。 彼（または彼女）が何を勉強し、発言し、考えているかを観察することで多くのことを学べるはずです。 周りにハッカーがいなければ、勉強会・カンファレンスに参加したり、ブログを利用してコミュニケーションをとるのもひとつの方法です。 「ハッカーに交わればハッカーになる」とまではうまくいきませんが、周りは自分より優秀な人ばかりであるという環境を作り上げる
プログラミングテクニックのまとめ - プログラミング日記
とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損
『コピー指向プログラミング』
以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
