C#プログラミングはメソッドが少ない方が良いのか。

前提・実現したいこと

UnityにてC#プログラミングの勉強をしています。
練習問題のようなものを出題され、自分で考えて書いてみたら結果は同じだったのですがコードが違いました。

私の方がメソッドが一つ多いので、良くなさそうというのはなんとなく分かります。
しかし、私はいまだ勉強中のため、大きなプロジェクトを作った経験がなく、この一見小さな違いが後々どう影響してくるのかが分かりません。

そこで、質問なのですが、この違いが後々どのように影響してきますか？
また、プログラミングはどのような形を目指していけば良いのですか？（例えば、同じことを書かない、メソッドは少なく等）

発生している問題

プログラミングの書き方を学んでいる最中だが、最終的にどのような形を目指していけば良いのか知らないことに気づいた。
より簡潔に、よりシンプルに、というのを目指していく事はなんとなく聞いたことがあるが、それがどんな形かは知らない。

該当のソースコード

C#
1//私の書いたもの
2public class Main : MonoBehaviour
3{
4    public delegate void Teleport();
5    public static　event Teleport onTeleport;
6
7    public void Teleporting()
8    {
9        if (onTeleport != null)
10        {
11            onTeleport();
12        }
13    }
14
15    private void Update()
16    {
17        if (Input.GetKeyDown(KeyCode.Space))
18        {
19            Teleporting();
20        }
21    }
22}

C#
1//私が書いたもの
2public class Cube : MonoBehaviour
3{
4    private void Start()
5    {
6        Main.onTeleport += ChangePosition;
7    }
8
9    public void ChangePosition()
10    {
11        GetComponent<Transform>().position = new Vector3(5, 2, 0);
12    }
13}

C#
1//公式の答え
2public class Main : MonoBehaviour
3{
4    public delegate void Teleport(Vector3 pos);
5    public static event Teleport onTeleport;
6
7    private void Update()
8    {
9        if (Input.GetKeyDown(KeyCode.Space))
10        {
11            if (onTeleport != null)
12            {
13                Vector3 pos = new Vector3(5,2,0);
14                onTeleport(pos);
15            }
16
17        }
18    }
19}

C#
1//公式の答え
2public class Cube : MonoBehaviour
3{
4    private void Start()
5    {
6        Main.onTeleport += ChangePosition;
7    }
8
9    public void ChangePosition(Vector3 pos)
10    {
11        transform.position = pos;
12    }
13}

行動規範の内容に同意します

回答4件

ベストアンサー

こんにちは。

なかなか微妙なケースと思います。このケースではどちらの記述でもOKと思います。
ただし、Update()関数が大きくなってきた時に差がでます。
行数の多い関数は分割した方が良い場合が多いのですが、ケースバイケースです。

大きなプログラムの多くは寿命が長く、かつ、関わる人も増えてきます。なので書いた人と別の人がメンテナンスすることも多々あります。
例えば今回のTeleporting()はたかだか数行の非常に小さな関数ですので、もしUpdate()関数の中に直接記述してあれば、そのまま読めば済みます。しかし別関数として定義してあると初めての人はインタフェースを把握する余分の手間を強いられます。

今回は引数も戻り値もないので問題ないですが、３～４個程度の引数は頻繁にあります。それらをきちんと把握する負担はなかなかのものです。その挙げ句、２～３行しか実行コードがなかったら、その関数を把握する手間の大半はインタフェースの把握で消費されます。これはなかなかに悲しいことです。
ですので、１箇所からしか呼ばれない数行程度の小さな関数は呼び出し元に直接記述した方が好ましい場合が多いです。

大きな関数を分割する目的は見通しをよくすることです。小さすぎる関数を多発させるなど、それに反するような分割はしないことをお勧めします。

「どのように記述すると見通しが良くなるか」は、分かりやすい文章を書くスキルと同じようなものです。
読みにくいコードに出会う度に何が原因か考えつつ、経験を積むことが効果的と思います。

投稿2020/09/18 16:51

Chironian

総合スコア23272

うーん、どうでしょうね。
個人的には、メソッドに分割したほうが良い事のほうが多いです。
もちろん、メソッド名が適切である事、処理の分け方が適切である事が前提ですが、
メンテナンスしやすさ、コードの読みやすさはメソッド分割のほうが高いです。
ただ、提示された程度のコードの長さだとどっちでも良いのかなと思います。

実際のゲームのコードはもっと長くて複雑になって来ますから、1つのメソッドの行数が増えて、
そこに複数の処理が入って来たら、メソッドを分割しないとダメです。

メソッドの分け方とかは、知識よりも経験則のほうが大きい事が多いように思います。
苦労した経験があって初めて分割のメリットを理解できるというか。
なので、ある程度複雑で長い行数のコードを書いて、それをメンテナンスする＝(仕様変更や機能追加)経験を繰り返して、やっぱりコードは分割したほうがいいなという経験をしてから自然と答えにたどり着くような気もしています。

投稿2020/09/18 15:54