3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

秒でインスタンス変数を読み取り専用にする by Visual Studio

Posted at

この記事は

Qiita Engineer Festa 2022のテーマ「悪いコードを改善した時の体験や知見を共有しよう」に寄せて書いた記事です。

具体的なコードには言及せず、Visual Studioを使って手軽にできるプチ改善方法を共有します。

👉対象読者: Visual StudioとC#を使っている初心者エンジニア

コード改善の基本スタンス

一言で「悪いコード👿」といっても、いろいろな種類の悪さ/症状があるかと思います。
それらの症状に広く適用できる改善方法の1つが・・・

インスタンス変数はなるべく不変にしよう!!」です✨

// 不変とは、再代入を禁止すること

// 再代入とは
int a = 1 // 宣言したあとに
a = 2     // 違う値を代入すること

インスタンス変数が可変であると起こりうるリスクについて

ある程度大きいクラスになると、各メソッドが同じインスタンス変数を使う確率があがります。
あるとき、変数の値を書き換えるメソッドが出現します。

同じクラスに、変数の値が書き変わらないことを前提に作ったメソッドがあった場合、そのメソッドは予期せぬ結果を返します。
予期せぬ結果はいずれ表面化し、品質リスクになります。

変数を書き換えるメソッドを特定して、タイミングを見計らってメソッドを使ってもらうよう周知します。
しかしそのアナウンスはいずれ忘れ去られます。
そして不幸は繰り返されます😱

変数を不変にしよう、そうしよう

変わるから予期できないんだ。だったら変えることを禁止してしまえばいい😀

変数の頭にreadonly修飾子をつけます!  ※ C#の場合

readonly int abc; // 読み取り専用の変数 abc

でも、変数を不変にするのが怖い

恐る恐る、巨大クラスの上のほうにあった変数にreadonlyをつけた
コードがエラーで真っ赤になった! 😨

image.png

変数が多すぎて、どれを不変にしていいかわからない

おもいきって、置換機能ですべての変数にreadonlyをつけた。
コードがエラーで真っ赤になった!! 😨(2回目)

image.png

【解決策】Visual Studioに助けてもらおう

IDE, 統合開発環境のチカラを借ります🔧

手順はたった2つです。20秒でできます⏰

コードクリーンナップの構成

Visual Studioの検索窓に「コードクリーンナップの構成」と入力、クリックするとダイヤログが表示されます。

image.png

フィールドを読み取り専用にしますを追加してOK

image

コードに戻って、Ctrl+K + Ctrl+Eを押す

Ctrlに小指を置いたまま、KEの順に押すと・・・

animation.gif

読み取り専用にできる変数にはreadonlyが勝手に付与された! 🎉
widthheightのこと)

一方で、countはメソッドの中で変更されるので、readonly対象外。

もちろんこのままコンパイルも通ります。先ほどのようにエラー続出にはなりません。

このあとどうする?

countをどうにかできないか考えます。リファクタリングというものです。

  • インスタンス変数ではなく、メソッド内のローカル変数してスコープを小さくできないか?
    • できないなら、countを変更するだけのメソッドを用意する
      • 変数がどこで使われているかよりも、メソッドがどこで使われているかを追うほうが簡単
    • メソッドに切り出す際は、副作用(冪等性)やコマンドクエリ分離原則を意識する

おわりに

Visual Studioには、無駄な条件分岐をシンプルにしたり、名前の変更を一括で行ったりと、コードの改善を手助けしてくれる機能がたくさんあります。
どんどん活用していきたいですね🙌

手前みその関連記事:Visual Studio 2019 を入れて最初に行う設定

おまけ

readonly以外にもinIReadOnlyCollection<T>を使うと、読み取り専用スキルがアップ!!

エピローグ

悪いコードを改善した時の体験や知見を共有しよう」を初めに見たとき
新人のころに出会った数々のコードが頭に思い浮かんだ

しかし、いざ再現して悪いところを指摘しようとしても、なかなか言語化できないことに気づいた
変更するのが凄い手間だったり、変更して正常に動かなくなるのが怖かったのは確かなのに
いざどこをどうすればよかったのかを考えると、手が止まる

おそらくその理由の1つは、どうしようもなくダメなところが多すぎて1記事にはおさまらないことだと思う(やや言い訳がましいが)
ex)ベタ書きやグローバル変数を使うより、ユースケースごとにクラスを分けて、クラスごとに使う変数だけをDIしたリポジトリから引っ張ってきて、、、orz

もう1つの理由は、やはり自分がその改善策に自身がもてないからだと反省。勉強します。

そして結局は手軽に明日から使える手先の小ネタに逃げた記事になった

何かコード的にアブナイことをしている人(またはチーム)に対して
「これは〇〇という場合に▼▼ということが起きてアブナイから■■にしてみたら?」と言うのは簡単だけど、その■■の裏にも前提となるベストプラクティスがあって
順序立てて説明(教育)しないと納得してもらえない。「なんで動いているのにそんな遠回りをするんだ」と言われる

つまり

人は、自分がよく分かっていないことは正しく説明できないですし、曖昧でぼんやりするものです。
より正しく精密に理解しているものほど、的確に言語化できます。
引用元:https://qiita.com/official-events/535fdbb5cb67791998f8

を身に染みてわかった取り組みになりました。おわり。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?