問灯(といあかり) Toiakari問灯(といあかり) Toiakari
ホームみつける連載
問いを立てる
ログイン
問灯について利用規約プライバシーポリシーAIの利用について子どもの安全ヘルプ・お問い合わせアプリ

© 2026 問灯(といあかり)

創作センター

問いを立てる・観点を書く・記事や連載をつくる。あなたの創作の入口。

書きはじめる

急上昇の問い

  1. 1バドミントンのシャトルの羽、なぜ斜めに落ちる?
  2. 2推し活グッズの飾り方、色数が多すぎて統一感がない
  3. 3積みゲーを『途中でやめる』と決めたら、心理的に次のゲームに進めるようになった
  4. 4家計簿アプリ、固定費と変動費の分類ルールが曖昧すぎて毎回迷う
  5. 5食事記録、「今日何食べたっけ?」が思い出せず後から入力できない
  6. 6毎週同じ曜日に自炊するはずなのに、準備段階で挫折する
もっと見る
問灯について利用規約プライバシーポリシーAIの利用について子どもの安全ヘルプ・お問い合わせアプリ厳選ストーリー

© 2026 問灯(といあかり)

ホームみつける通知マイページ
型システムで『null許容性』と『Option型』の使い分け、どう決めてますか?1/1
佐
佐々木 颯太

10月21日

正直なところ、最初は両者の違いをちゃんと理解できてなかったんですよね。nullが許容される型と、Option型を使い分ける理由がピンとこなくて。でも実際にコード書いてると、その違いの大事さが見えてきた気がします。

私の場合、ユーザーが入力するデータを扱う時に気づきました。例えば、住所の「建物名」みたいに「あってもなくても成り立つ」データってありますよね。最初はnull許容で放り込んでたんですけど、後で別の処理を追加する時に「この値、nullかもしれない」をいちいち思い出さないといけなくなって…。地味にバグの原因になってました。

Option型を使い始めたら、型の段階で「ここは値がない可能性がある」が明示されるようになった。コード読む時も、その値を使う時も「あ、nullチェックいるんだ」って分かりやすくなって、ミスが減った感じがします。

ただ、APIからのレスポンスとか、外部から来るデータについては、まだnull許容で受け取ることもあるんですよ。その後、確実に変換してOption型にするみたいな流れで。完全に統一できてるわけじゃないですけど、その使い分けが自分の中でのルールになってきた感じです。チームだと逆に厳格に統一した方がいいんだろうなって思ってます。

著作権は著者に帰属します

いいね 0・コメント 0・保存 0

この観点から問いを立てる

コメント

0
問いへ戻る