When to use symbols instead of strings in Ruby?
TL;DR A simple rule of thumb is to use symbols every time you need internal identifiers. For Ruby < 2.2 only use symbols when they aren't generated dynamically, to avoid memory leaks. Full answer The only reason not to use them for identifiers that are generated dynamically is because of memory concerns. This question is very common because many programming languages don't have symbols, only strin
防御的プログラミング - Strategic Choice
プログラマー道具箱の必需品、「Code Complete第2版〈上〉―完全なプログラミングを目指して」の「第8章 防御的プログラミング」をまとめます。目次防御的プログラミング・防御的プログラミングとは防御的プログラミング・予想されないエラーの処理防御的プログラミング・予想されるエラーの処理防御的プログラミング・例外防御的プログラミング・バリケード防御的プログラミング・デバッグエイド防御的プログラミング・なぜ防御的プログラミングかエントリのコンテキスト各エントリはフラットではなく、以下アウトラインに沿っています。黒字はコンテキストや要素、赤字がエントリ名です。出典Code Complete第2版〈上〉―完全なプログラミングを目指して作者: スティーブマコネル,Steve McConnell,クイープ出版社/メーカー: 日経BPソフトプレス発売日: 2005/03メディア: 単行本購入: 27
防御的プログラミング・防御的プログラミングとは - Strategic Choice
防御的プログラミングを概観します。防御的プログラミングとは「防御的プログラミング｣は、｢そうなるはずだ｣と決め付けないプログラミングです。この発想は「防御運転*1」にヒントを得たものです。防御運転では「他のドライバーが何をしようとするか全くわからない」という心構えを持ちます。そうすることで、他のドライバーが危険な行動に出たときに、自分に被害が及ばないようにします。たとえ他のドライバーの過失であっても、自分の身は自分で守ることに責任をもつ姿勢です。これに倣い、防御的プログラミングは、ルーチンに不正なデータが渡されたときに、それが他のルーチンのせいであったとしても、被害を受けないように実装します。プログラムには必ず問題があり、プログラムには必ず変更があり、プログラマはそれを踏まえて「防御的に」コードを開発する必要がある、ということです。防御の観点完成したソフトウェアは、「不正な入力」に対して防
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則: 上田勲: 本
