『あなたにもできること』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 私はいつも「読みやすいコードを書け」と言っている。そのためにできることは、決して難しいことばかりではない。 例えば、次のようなソースコードをみると、いつも思うのだ。 private static final String DATA[][][] = { {"ringo","gorira","rajio","ondanka","kaimenjoushou"}, {"5","5","4","7","12"}, {"K100","J1","U200","X203","W9800"} }; どうして、こんな風に揃えて書かないのだろうか？ private static final Str
『コピー指向プログラミング』
以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想
『ドキュメント内のリテラルにも注意』
というように、決まった値を持つようなもの（名義尺度や順序尺度 ）である。 プログラミングでこうした値を扱う場合は、数値やコード値をそのまま（リテラル ）では記述せず、定数を定義して、それを使う。あるいは、「列挙型 」を扱える言語であれば、そちらを使う。 ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない（もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが）。 これはプログラマにとっては基本的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。
『プログラマは考えるのが仕事』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 私の職場では２つ穴のパイプファイル（リングファイル）をよく使う。そのため、私はデスクの上にハンディタイプの２穴パンチを置いている。紙の縁に噛ませてパチンと鋏むだけの、よくあるやつだ。 あるとき、若いプログラマがこのパンチを借りに来た。何気なく彼の様子を見ていると、紙の真ん中を決めるのに苦労しているようだ。私のパンチには紙の位置を合わせるためのガイドが付いていないので、うまくできないのだろう。バインダーに綴じられた紙は、縁が揃っておらず、ガタガタになっていた。 こういうパンチを使うときは、紙を半分に折って、折り目をパンチの真ん中（目印がついている）に合わせるのである。もちろん、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
