書くなどなど色々あると思います。実際はある一つの方法だけを選ぶのではなく状況に合わせて書く事が多いと思います。書く場所を決めているかを紹介したいと思います。作るのは結構メンテナンス性が悪いと思うので気をつけて実装するようにしています。まとめたい場合とかは、それと分かるような名前をつけます。なんでもいいと思います。テスト不要なもの例えば3文字ごとにスペースを入れた文字列を表示したいという(謎の)仕様がある場合。して書くことが多いです。スコープ的にテストコードから見えなくなるのでテストが不要なぐらい簡単な場合にはこの方法を取ります。アクセスできないので安全です。仕様が変わっても安心して修正できます。他の箇所から使うことを想定していないので、プロパティ・メソッド名が短くて済みます。命名の負荷が減るのはいいこと。ない場合に何が起こるかを説明します。予期せぬ変更が発生してしまいます。「テストしとけば大丈夫でしょ」という意見もあると思いますが、現実問題で網羅するのは大変なので間違いが発生しにくいコードを書いたほうが有益だと考えています。そのものが再利用できないか考えましょう。StringDisplayHogeExtension.swift。作らない解決方法もありです。テストができるのでそこからテストします。}}ユーザーからの入力をバリデーションする場合もこの書き方をすることが多いです。メソッドとして書いたらいいのでは?」と思う人もいるかも知れないです。僕的にはそういう方法はなんかイケてないのでしません。して切り出しておいたほうが依存関係がスッキリしてあとからの修正に耐えられるコードになります。中に書いてください」とレビューで指摘されることがあって泣く泣く治す場合もあります。どこに書くのかの方針を書きました。いう話もあるなと思ったのですが、今回はそれには触れませんでした。コードを書く際の参考になれば幸いです。Navigationを使って型安全にパラメータを渡すこんにちは、id:numanuma08です。ひさびさにAndroidネタです。11はてなブログをはじめよう!covellineさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。