「C#」の記事 - Crieit

【C#】戻り値がvoidなメソッドで、式形式メンバー＋三項演算子を使う

2022-06-13T18:26:17+09:00

できるのかな？と思って興味本位でなんやかんややってみたのでメモです。

次のようなメソッドがあるとします。

void DoSomething()
{
    // 何らかの処理
}

void DoSomethingIfNeeded(bool isNeeded)
{
    if (isNeeded)
        DoSomething();
}

この時、DoSomethingIfNeeded をシンプルに式形式メンバーで書きたいと思いました。イメージとしてはこんな感じ。

void DoSomethingIfNeeded(bool ifNeeded)
    => isNeeded ? DoSomething()
                        : null;

上記コードはコンパイルが通りません。void なのに null を返しているからです。

だったら処理のない DoNothing 的なメソッドを実行させれば良いのでは？と思い、次のように書いてみました。

void DoNothing()
{
    return;
}

void DoSomethingIfNeeded(bool isNeeded)
{
    isNeeded ? DoSomething()
                  : DoNothing();
}

しかしこれもコンパイルエラーになります。

CS0201: 代入、呼び出し、インクリメント、デクリメント、新しいオブジェクトの式のみがステートメントとして使用できます

なるほど…。それなら三項演算子には、どのメソッドを呼び出すかの判定だけをしてもらえばいいのでは？

ということで下記のように書いてみました。

void DoSomethingIfNeeded(bool isNeeded)
    => ( isNeeded ? DoSomething : DoNothing )();

これなら、やっていることは DoSomething か DoNothing かだから通るでしょう、という魂胆です。しかしこれも通りません。

CS0149: メソッド名が必要です

そうですか…。

いやいやおかしいでしょ、実行すべきメソッドを決定しているのに、メソッド名が必要なのは変では？と思い調べてみたところ、以下の記事にたどり着きました。

僕はね、voidが戻りの関数を三項演算子みたいに使いたかっただけなんだ
https://qiita.com/vranometria/items/cfe6f282d7973ae7f52b

キャスト…。どちらも Action であることは明らかだと思うのだけど、明示的なキャストが必要なのか…。何故…。

キャストを入れてみます。

void DoSomethingIfNeeded(bool isNeeded)
    => ( isNeeded ? (Action)DoSomething : DoNothing )();

これでコンパイルが通りました。

あとは、何もしない処理にわざわざ DoNothing という名前を付ける必要もないので匿名化します。

void DoSomethingIfNeeded(bool isNeeded)
    => ( isNeeded ? (Action)DoSomething : () => { } )();

これで一応、当初の目的は達成できました。DoSomething に簡単な処理を入れて実行してみます。

void DoSomething()
{
    Console.WriteLine("hoge");
    Console.WriteLine("fuga");
}

void DoSomethingIfNeeded(bool isNeeded)
    => ( isNeeded ? (Action)DoSomething : () => { } )();

DoSomethingIfNeeded(true);
Console.WriteLine("piyo");

// hoge
// fuga
// piyo

DoSomethingIfNeeded(false);
Console.WriteLine("piyo")

// piyo

できました。キャストが必要な理由は勉強が必要。

参考

僕はね、voidが戻りの関数を三項演算子みたいに使いたかっただけなんだ
https://qiita.com/vranometria/items/cfe6f282d7973ae7f52b

Expression-bodied members (C# programming guide)
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members

【C#】LINQ のメソッド名が SQL っぽいからラップする

2022-06-06T18:50:19+09:00

SQL チックなメソッド名

C# の LINQ to Object（以下、単に LINQ と記載）はとても便利なんですけど、メソッド名が SQL っぽくて、いまいち直感的ではない上にダサいです。例として、JavaScript と比較してみましょう。

LINQ でのメソッド名	JavaScript のメソッド名
Select	map
Where	filter
OrderBy	sort

以下は、実際に利用する例です。
JavaScript ではこう。

const hoge = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0];
const fuga = hoge.filter(x => x % 2 === 0).map(x => x * 2).sort();

C# ではこう。

var hoge = new[] { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
var fuga = hoge.Where(x => x % 2 == 0).Select(x => x * 2).OrderBy(x => x).ToArray();

もちろん慣れてくれば Select だろうが Where だろうがスラスラ読めるのですが、慣れていなければ引っかかるかもしれません。一方、map, filter, sort というのは直感的で意味がわかりやすいです。

ラップする

ということで、ラッパーメソッドで名前を変えます。

`Select` => `Map`

public static IEnumerable Map(this IEnumerable source, Func func)
    => source.Select(x => func(x));

public static IEnumerable Map(this IEnumerable source, Func func)
    => source.Select((x, index) => func(x, index));

`Where` => `Filter`

public static IEnumerable Filter(this IEnumerable source, Func func)
    => source.Where(x => func());

public static IEnumerable Filter(this IEnumerable source, Func func)
    => source.Where(x => func(x));

public static IEnumerable Filter(this IEnumerable source, bool func)
    => source.Where(x => func);

`OrderBy` => `Sort`

public static IOrderedEnumerable Sort(this IEnumerable sources, Func keySelector, IComparer comparer)
    => sources.OrderBy(keySelector, comparer);

public static IOrderedEnumerable Sort(this IEnumerable sources, Func keySelector)
    => sources.OrderBy(keySelector);

public static IOrderedEnumerable SortByDesc(this IEnumerable sources, Func keySelector, IComparer comparer)
    => sources.OrderByDescending(keySelector, comparer);

public static IOrderedEnumerable SortByDesc(this IEnumerable sources, Func keySelector)
    => sources.OrderByDescending(keySelector);

ソートに関しては、元の OrderBy が、昇順か降順かでメソッドが別れています。昇順のソートが OrderBy、降順のソートが OrderByDescending なので、それぞれ Sort、 SortByDesc というメソッド名でラップしましたが、ここは昇順か降順かをオプション引数で切り替える Sort という名前のメソッドにしても良いでしょう。

「昇順か降順かをメソッド名だけで判断できる」という利点はありますが、同じようなことが別の名前のメソッドで定義されているのも、個人的には気持ち悪いと感じます。

同様に、ThenBy と ThenByDescending も Then というメソッドでラップしてみます。

public static IOrderedEnumerable Sort(this IEnumerable sources, Func keySelector, IComparer comparer, bool byDesc)
    => byDesc ? sources.OrderByDescending(keySelector, comparer) 
              : sources.OrderBy(keySelector, comparer);

public static IOrderedEnumerable Sort(this IEnumerable sources, Func keySelector, bool byDesc)
    => byDesc ? sources.OrderByDescending(keySelector)
              : sources.OrderBy(keySelector);

public static IOrderedEnumerable Then(this IOrderedEnumerable sources, Func keySelector, IComparer comparer, bool byDesc)
    => byDesc ? sources.ThenByDescending(keySelector, comparer)
              : sources.ThenBy(keySelector, comparer);

public static IOrderedEnumerable Then(this IOrderedEnumerable sources, Func keySelector, bool byDesc)
    => byDesc ? sources.ThenByDescending(keySelector)
              : sources.ThenBy(keySelector);

オプション引数 byDesc を設定しました。これにより、次のようにコードを書けます。

// ラップ前
var hoge = GetEmployee.OrderBy(s => s.Age).ThenByDesc(x => x.Salary);

// ラップ後
var hoge = GetEmployee.Sort(s => s.Age).Then(s => s.Salary, byDesc: true);

もちろん引数名の byDesc を省略することもできますが、理由があり記載しています。理由については、以下の記事で解説しているので、よかったらご覧ください。

【C#】あえて引数名を書くパターン

比較

メソッド名をラップしてみることで、冒頭のコードは次のように書けるようになりました。

// 変更前
var hoge = new[] { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
var fuga = hoge.Where(x => x % 2 == 0).Select(x => x * 2).OrderBy(x => x).ToArray();

// 変更後
var hoge = new[] { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
var fuga = hoge.Filter(x => x % 2 == 0).Map(x => x * 2).Sort(x => x).ToArray();

LINQ にあまり慣れていない人でも、よりスッと入ってきやすいコードになったのではないでしょうか。

【C#】あえて引数名を書くパターン

2022-06-02T19:00:09+09:00

C# では、メソッドやコンストラクタに引数を渡す際に引数名を省略してコードを書く場合が多いと思いますが、明示的に引数名を書くこともできます。

int Add(int x, int y)
    => x + y;

// 引数名を省略する場合
var hoge = Add(10, 20);

// 引数名を明記する場合
var fuga = Add(x: 10, y: 20);

省略しても問題ない引数名を、わざわざ明記するパターンは以下のような場合が考えられます。

複数の省略可能引数（オプション引数）のうち一つを明示的に指定する

void Demo(int x, bool isHoge = false, bool isFuga = false, bool isPiyo = false)
{
    Console.WriteLine($"x: {x}");
    Console.WriteLine($"isHoge: {isHoge}");
    Console.WriteLine($"isFuga: {isFuga}");
    Console.WriteLine($"isPiyo: {isPiyo}");
}

// isHoge と isFuga はデフォルト値のまま、isPiyo のみ指定
Demo(10, isPiyo: true);

// x: 10
// isHoge: False
// isFuga: False
// isPiyo: True

// 名前付き引数を使用しない場合、すべての引数を明示的に指定する必要がある
Demo(10, false, false, true);

これも、元々のメソッドの設計があまり良くないなどの理由で、後付けで省略可能引数がわんさか付いているようなメソッドというのは古いコードではよくあります。

可読性の向上；「この引数でどうなるんだっけ？」対策

例として以下の StreamWriter の場合を考えてみます。

var path = GetPath();
using (var sw = new StreamWriter(path, flase))
    sw.Write("hoge");

StreamWriter のコンストラクタの第2引数に false を渡しています。この第2引数は append という引数名で定義されており、既にファイルが存在する場合に末尾に書き込むか、新しく上書きするかを真偽値で指定します¹。

ところが数年ぶりに StreamWriter を使ってこのコードを見た場合、この false がどういう作用をもたらすのか瞬時に理解できるでしょうか？

もちろん、IDE上で見る場合は引数の説明をいつでも参照することができます。そうでない場合でも、公式のリファレンスソースを参照することができることでしょう。この false が何をもたらすかというのは、数十秒あれば解決できる疑問かもしれません。

しかし、引数名を明記しておくと数十秒とかからず、コードを見ただけで瞬時に判断できるようになります。

var path = GetPath();
using (var sw = new StreamWriter(path, append: flase))
    sw.Write("hoge");

「この false の引数名、append ってことはこの場合追記じゃなくて上書きなのか」と、定義やドキュメントを参照するまでもなくコードを読んだ瞬間に意味を理解することができます。これはかなり大きなメリットなのではないでしょうか。

さらに、今回は StreamWriter を例に出しましたが、もしこれが公式のライブラリではなく、ドキュメントもろくにメンテされていない独自ライブラリだとしたらどうでしょう。「そのような環境の方が問題だろ！」というのももっともですが、しかし全てのドキュメントのメンテが行き届いている環境ばかりではありません。

個人的には、コメントに「falseは上書き」みたいなことを書くよりは、append: false と書いた方が余程良いと思います²。

以上、個人的に想定する「引数名を明示する理由」をまとめてみました。

以下、おまけ。

最後のコメント的な用法に関しては、自作クラスを使う場合は WritingMode みたいな Enum を受け取るようにして、

using (var ow = OriginalWriter(path, WritingMode.Overwrite))
    ow.Write("hoge");

// WritingMode は
// WritingMode.Overwrite => 上書き
// WritingMode.Append    => 追記

という形で受け取るようにすれば、引数名を書かずとも「この引数では書込みモードを指定してますよ」という意図が明確になることもあります。自作する場合は、たとえ真偽値で判断できる場合でもあえて Enum を併用して、より意図を込めやすくなるように工夫できれば良いと思います。

参考 StreamWriter クラス｜StreamWriter(String, Boolean)
https://docs.microsoft.com/ja-jp/dotnet/api/system.io.streamwriter?view=net-6.0 ↩︎
コメントが悪という主張ではなく、コードで表現できることは、できるだけコードで表現すべきという主張です。たとえば「なぜ追記じゃなくて上書きをするのか」という意図が共有してあるのは良いコメントだと感じます。 ↩︎

【C#】え！！C#でif式を？できらぁ！

2021-11-17T20:22:26+09:00

タイトルは正確ではありません。すいません。if式っぽく書ける条件判定関数的なものです。if式っぽく書きたかったので作ってみました。

C#のifは文であって式ではありません。式ではないので

var name = "ほげほげ君";

// こうは書けない
var exName1 = if (name.EndsWith("君")) {
                return name;
              }
              else {
                  return name + "君";
              }

// こう書く
var exName2 = "";
if (name.EndsWith("君"))
    exName = name;
else
    exName2 = name + "君";

みたいに書かなければいけません。人によるかと思いますが、これ読みにくくないですか？exName2への代入が2箇所あるので読んでて鬱陶しいです。何度もこういうコードが出てくると嫌です。

このくらいのコードであれば三項演算子で解決するという方法もあるでしょう。

var name = "ほげほげ君";
var newName = name.EndsWith("君") ? name : name + "君";

これであれば代入は1箇所ですし分かりやすいですね。しかし、次のようなケースではどうでしょう。

// 三項演算子
var newName = name.EndsWith("さん") ? Regex.Replace(name, "さん$", "君") : (name.EndsWith("君") ? name : name + "君");

// if文
var newName = "";
if (name.EndsWith("さん"))
    newName = Regex.Replace(name, "さん$", "君");
else if (name.EndsWith("君"))
    newName = name;
else
    newName = name + "君";

最後が"さん"であれば"君"に変換するという場合は、三項演算子を使えば分かりにくくなり、if else if elseでは悪戯に長くなりますし結局代入箇所が分散していますね。もっとこう、スパっと書けないものでしょうか。ということでif式っぽいものを作りました。

// ex.1
var newName1 = Ext.If(name.EndsWith("さん"), Regex.Replace(name, "さん$", "君"))
                  .ElseIf(!name.EndsWith("君"), name + "君")
                  .Else(name);

あるいは

// ex.2
var newName2 = name.EndsWith("さん").Then(Regex.Replace(name, "さん$", "君"))
                                    .ElseIf(!name.EndsWith("君"), name + "君")
                                    .Else(name);

上記のように書くためのメソッドです。条件に対して欲しい結果をメソッドチェーンで書いていけるのでなんとなく読みやすいと思います。

まずはex.1にあるIf ElseIf Elseというメソッドがこちら。

public static Tuple If(bool term, T value)
{
    if (term)
    {
        // 条件が成立する場合はvalue
        return new Tuple(true, value);
    }
    else
    {
        // 条件が成立しない場合はT型のdefault
        return new Tuple(false, default);
    }
}

public static Tuple ElseIf(this Tuple prev, bool term, T value)
{
    if (prev.Item1)
    {
        // 前の式が成立している場合はそれをそのまま返す
        return prev;
    }
    else if (term)
    {
        // 条件が成立する場合はvalue
        return new Tuple(true, value);
    }
    else
    {
        // 条件が成立しない場合はT型のdefault
        return new Tuple(false, default);
    }
}

public static T Else Else(this Tuple prev, T value)
{
    if (prev.Item1)
    {
        // 前の式が成立する場合は、その値を取り出して返す
        return prev.Item2;
    }
    else
    {
        // 前の式が成立しない場合は規定値としてvalueを返す
        return value;
    }
}

if式を実現するにあたり、前の式の計算結果と値を受け取って引き継ぎつつ、最終的には値のみを返すという処理をする必要があります。そのため、Tupleでそれらの情報を受け渡し、最終的にElseでT型の値部分のみを返しています。

ElseIfとElseではTupleの拡張メソッドを使用しています。なので、このメソッドはstaticなクラスで宣言する必要があります。

続いてex.2にあるThenについて。ex.2のElseIfとElseはex.1のものと同様です。

public static Tuple Then(this bool term, T value)
{
    if (term)
    {
        // 条件が成立する場合はvalue
        return new Tuple(true, value);
    }
    else
    {
        // 条件が成立しない場合はT型のdefault
        return new Tuple(false, default);
    }
}

これも単純にex.1のIfの引数termを、引数ではなくメソッドチェーン的に取れるようにthisキーワードで拡張したメソッドになります。thisキーワードにしている引数は明示的に指定することも可能なので、なんならex.1のIfメソッドをこのThenメソッドで代用することも可能です。(条件を指定するならIf的な名前がいいと思って別に定義しました)

ElseIfは必要に応じて省略することも、複数記述することもできます。

var point = GetPoint();
var score = Ext.If(point == 100, "S")
               .ElseIf(point >= 80, "A")
               .ElseIf(point >= 60, "B")
               .ElseIf(point >= 40, "C")
               .ElseIf(point >= 30, "D")
               .Else("E");

このように書けます。if文でちまちま書いたり三項演算子でネストして書いていくよりはるかにわかりやすいと思います。

FuncやActionを受け取るよう拡張すれば、ラムダ式などを使ってより柔軟な表現が出来るようになると思います。たとえばActionだと、

public static bool Then(this bool term, Action action)
{
    if (!term)
        return false;

    action();
    return true;
}

public static bool ElseIf(this bool previous, bool term, Action action)
{
    if (previous)
        return true;
    else if (!term)
        return false;

    action();
    return true;
}

public static void Else(this bool previous, Action action)
{
    if (previous)
        return;

    action();
}

// ***

var point = GetPoint();
(point == 100).Then(() => Console.WriteLine("S"))
              .ElseIf((point >= 80), () => Console.WriteLine("A"))
              .ElseIf((point >= 60), () => Console.WriteLine("B"))
              .ElseIf((point >= 40), () => Console.WriteLine("C"))
              .ElseIf((point >= 30), () => Console.WriteLine("D"))
              .Else(() => Console.WriteLine("E"));

こんな感じで書けます。

ジェネリクスを使用していますが制約などはつけていませんし、より最適なコードもあるかもしれません。ある程度拡張性はあると思いますが、もっといいやり方あるよ！などがあれば、是非教えてください。

C#(.Net 6)でgRPCサーバー on Mac

2021-11-12T01:52:27+09:00

.Net 6 も出たし……と思い、C# で gRPC のサンプルをMacで動かそうとしたらエラーで落ちてちょっと戸惑ったので、手順を書いておきます。

手順

テンプレートからプロジェクトを作る

gRPCのテンプレからプロジェクトを作ります。

$ dotnet new grpc -o GrpcGreeter

実行（落ちる）

普通に実行します。するとMacでは落ちます。

$ cd GrpcGreeter
$ dotnet run
ビルドしています...
Unhandled exception. System.IO.IOException: Failed to bind to address https://localhost:7229.
 ---> System.AggregateException: One or more errors occurred. (HTTP/2 over TLS is not supported on macOS due to missing ALPN support.) (HTTP/2 over TLS is not supported on macOS due to missing ALPN support.)

実行

これで実行できます。

$ dotnet run
ビルドしています...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5142
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /Users/suzusime/sandbox/GrpcGreeter/

その他

protobufのパスは GrpcGreeter.csproj で指定できるようになっています。protobufを変更しても、dotnet runしたときにいいかんじにC#のファイルも生成してくれるようです。
サーバーの実装は Services/GreeterService.cs にあります（見れば分かりますが）。Greeter.GreeterBaseという自動生成される基底クラスを継承してオーバーライドしていく方式みたいです。

所感

テンプレに従うだけで動かせるので、とりあえずgRPCを試してみたいという需要ならGoでやる以上に楽ですね。

あと、Visual Studio for Mac 2022 Previewも入れてみたのですが、重くて正直微妙でした。VS Codeの出来が良すぎる……。

C#のif文の波括弧{}について

2021-10-26T20:31:27+09:00

C#ではifなどの{}を省略¹して書けます。たとえば

// これを
if (girl.IsBoyish)
{
    Console.Write("かわいいね");
}

// こう
if (girl.IsBoyish)
    Console.Write("かわいいね");

こんな感じで書ける訳ですね。タイプ量が減りますし個人的にはこのスタイルが好きです。

ただしあくまでifの後が単一の処理の場合なので、girl.IsBoyishがtrueの場合は「（１）コンソール出力」と「（２）ボーイッシュリストに入れる」ということをしたい場合に

if (girl.IsBoyish)
    Console.Write("かわいいね");
    boyishGirls.Add(girl);

こういう風には書けません。C#はインデントをブロックとして解釈しないので、このコードは下記の様に解釈されます。

if (girl.IsBoyish)
{
    Console.Write("かわいいね");
}
boyishGirls.Add(girl);

この場合、「（１）コンソール出力」はgirl.IsBoyishがtrueの場合のみですが、「（２）ボーイッシュリストに入れる」はgirl.IsBoyishがfalseでも実行されてしまいます。

ボーイッシュリストにボーイッシュじゃない女の子が入っていると都合が悪いですよね？ね？

なので、正しくは

if (girl.IsBoyish)
{
    Console.Write("かわいいね");
    boyishGirls.Add(girl);
}

と書かなければなりません。

※実際にはifの{}を省略して複数行書くと、boyishGirls.Add(girl);の行のインデントはIDEなどでは効かないので、ifの範囲外ということはすぐに分かると思います。

こういう事情があるので、ifとelseが連続するような判定では{}を省略すると意図しない結果になる場合があります。たとえば次のようなケースをプログラムで表現するとします。

if (!girl.HasShortHair)
{
    if (girl.IsBokuGirl)
    {
        Console.Write("かわいいね");
    }
}
else
{
    Console.Write("かわいいね");
}

上記は「女の子がショートヘアでなく、かつボクっ娘である」または「女の子がショートヘアである」場合にコンソール出力をするというコードです。

※この条件判定は私の趣味ですが「ショートヘアでもボクっ娘でもない女の子は可愛くねぇ！」という主張ではありませんのでご承知おきください。

これを、{}を省略しようと思って下記のように書くとします。

if (!girl.HasShortHair)
    if (girl.IsBokuGirl)
        Console.Write("かわいいね");
else
    Console.Write("かわいいね");

一見{}を省けたように見えますが、前述の通りC#ではインデントはブロックとして解釈されません。つまり、上記のコードは下記のように解釈されます。

if (!girl.HasShortHair)
{
    if (girl.IsBokuGirl)
    {
        Console.Write("かわいいね");
    }
    else
    {
        Console.Write("かわいいね");
    }
}

するとどうでしょう、「女の子がショートヘアでない場合、ボクっ娘であればコンソール出力、ボクっ娘でなくてもコンソール出力」「女の子がショートヘアの場合は何もしない」というコードになってしまいました。意図が真逆になっています。

なので、こういうケースでは{}を使ってelseがどのifに対応しているものなのかを明示的に記載する必要があります。

if (!girl.HasShortHair)
{
    if (girl.IsBokuGirl)
        Console.Write("かわいいね");
}
else
    Console.Write("かわいいね");

上記のようにすれば問題なく、本来の要件を満たす条件判定となります。個人的な好みとしてはifに{}を付けるならelseにも{}を(単一処理でも)付けたいです。

ifの{}を省略する場合は、シンプルな処理であればタイプ量も減りシンプルで見通しの良いコードになりますが、複数条件が入り組んだ式の場合は注意が必要です。

※説明のために意図的に分かりにくく書きましたが、上記の例であれば

if (girl.HasShortHair || girl.IsBokuGirl)
    Console.Write("かわいいね");

のようにロジックを見直して吸収できたりもするので、柔軟に考えてみると良いと思います。

C#の歴史的背景に詳しくないのですが、「もともとifはそれに続く単一の処理をするのであり、{}で複数の処理を単一の処理っぽくしているのであって、省略とかではなく本来{}がないのが成り立ち的には正しいのである」とか…。 ↩︎

C#でゲームを作った話

2021-07-08T00:31:43+09:00

はじめに

C#でゲームを作りました。

ゲームの詳細やダウンロードは以下からどうぞ。
ダウンロード

今回はC#でゲーム作ろうとした経緯から完成して配布までに感じた事を書いてみます。C#でというか、ゲーム作成ツールを使わずにゼロからまともにゲームを作ったのは初めてですので、その視点からの学びも記録します。

自分は仕事でSEをやっていますが、去年、緊急事態宣言が始まったタイミングでその時の出向先での業務が次の現場が決まらないまま終わりました。
今は普通に仕事はありますが、あの頃は一時的にSEの仕事も減った印象があります。
で、仕方ないので3か月間ほど、Teamsを使って同じく仕事がなくなった自社の若いメンバーにC言語、C++と、（自分もほとんど触ったことのない）C#を何故か教えていました。それがきっかけでC#を勉強し、勉強しつつ何か作ろうってことで今回のゲームを作り始めました。

なぜコンソールアプリ・・・

UnityとかGUIなやつだと、C#での実装以外の作業が多くなるかなと思ったのと、どんどん盛りだくさんになっていって絶対最後まで完成しないと思ったからです。
多分その予想は正しかったと思います。

セーブデータはどうする

作る前からゲームのセーブデータをどうしようって思っていました。
いざ作る時になって腹を決めて調べたら、.NETにはオブジェクトの内容をXMLの形で書き出し・読み出しができるクソ便利なクラスがあったのでそれを使う事にしました。詳しくは「.NET XML シリアライズ」で検索してください。
実際にはセーブデータとして書き込み・読み出しされるSaveDataクラスを用意して、その中にセーブデータとして残したいメンバをぶちこみます。でSaveDataのインスタンスをXMLシリアライズ・デシリアライズしてsave/loadを実現しました。もちろんそのままだと簡単に編集できてしまうので、XMLデータの暗号化・複合化も行っています。

この時注意したいのが、「SaveDataにreadonlyのデータを含めない」事です。セーブデータの容量が無駄に増えるだけの話ではありません。ゲームのアップデートでそのreadonlyのデータに変更が入っても、アプデ前のセーブデータを使うと当然ながらアプデ前のreadonlyデータになってしまい、変更が反映されなくなってしまう可能性があるからです(セーブデータに互換性がなくなる)。

「readonlyのデータをセーブデータに含めるわけねーだろ」って確かにその通りなのですが、最初にしっかり設計できていればの話で、最終的に1つのstructの中にreadonlyとそうでないデータが混在している・・・ってあるんじゃないでしょうか？　無い？

テスト

今回は、完成後のテストを十分に行いました。これの前に作ったゲームがあるのですが、そっちはあまりテストせずに公開し、延々とバグ報告があがる恐怖を味わいました。
何故ろくにテストせずに公開したのかというと、完成間近の時は、早く遊んでもらいたい、反応を見たいという欲がすごくなってしまったからです。今回もその誘惑がすごかったのですが、なんとか耐えてテストしきりました。
前に作った方はジャンル効果で幸運にも沢山遊んでいただき、フィードバックも十分にあったので結果オーライだったのですが、もしあまり遊ばれなかったらバグもそのままで、あとになって自分でプレイしたときに「こんなバグを誰からも指摘されず自分で発見してしまうなんて・・・全然遊ばれてなかったのか・・・・」と立ち直れなくなると思います。

.NETアプリの難読化

.NETで作ったアプリは、ほぼそのままのソースでリバースエンジニアリングできてしまうという特徴があります。なのでMicroSoftも難読化を推奨しているのですが、やる気になって色々難読化ツールを調べて使ってみても、以下の問題がありました。

・難読化したら動かなくなった
・難読化するとウイルス判定されやすくなった
・使えそうな難読化ツールがみんな有料(しかも高価)

どうしろと？みたいな状況です。
仕方ないので、VisualStudio経由でインストールできるDotfuscatorのCE版を使用しています。
ただしこれは、かなり甘い難読化です。文字列リテラルとかそのままです。
DotfuscatorのCE版より高機能で、無料でできる、ウイルス判定されない難読化ツールあったら教えてください。(切実)

どこで配布するか

今回はファイルそのものはふりーむさん一本にしました。
配布元は↑一本ですが、フリーゲーム夢現さんにも登録して入り口を増やしています。
前回はBOOTH、Vectorにも置きましたが、ゲームの場合は感想やコメントをもらいやすく、アプデも検知されやすい(かもしれない)ふりーむと夢現に絞った方がよいのではないかと思いました。
ちなみに、適当なアップローダーに置いて配布するのはやめましょう。ダウンロード先が信用できないとして、要注意アプリ扱いされる場合があります。

最後に

今回のゲームが完成間近のタイミングで、任天堂から「ナビつき！つくってわかるはじめてゲームプログラミング」がリリースされました。購入しましたが、今回のゲームが完成し、燃え尽きてなにもゲームのアイデアが無く、全然何も作れてない状態です。チュートリアルは全部クリアしましたが、正直このまま積みそうです。
ゲームのアイデアは尽きてますが、せっかくC#を勉強したので、Unityもやってみたいですね。勉強だけして満足しそうな気がしますが。

C# 8.0のswitch式

2021-05-08T22:36:30+09:00

switch式

C#のswitchが、C# 8.0から式で使えるようになってます。いいですね。

良い例が思い浮かばないのが申し訳ないですが、このようなEnumがあるとします。

public enum DayOfWeek
{
    Sunday,
    Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday,
}

ある日付の曜日を日本語で表示するためのswitchを使用するとします。従来はこのように書いていました。

var dow_eng = DateTime.Today.DayOfWeek;
var dow_jpn = "";

switch ((DayOfWeek)dow_eng)
{
    case DayOfWeek.Sunday:
        dow_jpn = "日曜日";
        break;
    case DayOfWeek.Monday:
        dow_jpn = "月曜日";
        break;
    case DayOfWeek.Tuesday:
        dow_jpn = "火曜日";
        break;
    case DayOfWeek.Wednesday:
        dow_jpn = "水曜日";
        break;
    case DayOfWeek.Thursday:
        dow_jpn = "木曜日";
        break;
    case DayOfWeek.Friday:
        dow_jpn = "金曜日";
        break;
    case DayOfWeek.Saturday:
        dow_jpn = "土曜日";
        break;
    default:
        dow_jpn = "エラー";
        break;
}

Console.Write(dow_jpn);

なっが～～。これいちいちcaseとかdefaultとかbreakとかだらだらと書かなきゃいけなくて、すごく面倒ですよね。

これがC# 8.0ではこう書けます。

var dow_eng = DateTime.Today.DayOfWeek;
var dow_jpn = (DayOfWeek)dow_eng switch
{
    DayOfWeek.Sunday => "日曜日",
    DayOfWeek.Monday => "月曜日",
    DayOfWeek.Tuesday => "火曜日",
    DayOfWeek.Wednesday => "水曜日",
    DayOfWeek.Thursday => "木曜日",
    DayOfWeek.Friday => "金曜日",
    DayOfWeek.Saturday => "土曜日",
    _ => "エラー",
};

Console.Write(dow_jpn);

すっきりしましたね。特徴としてはswitch式なので、それ自体が文字列を返してくれます。長ったらしくcaseとかを書かずに済むのはとても良いですね。

defaultに当たる処理は_とマッチさせます。

`_`が使われている場合は無視される

C#はstringもswitchに使用できます。その場合、caseには変数(定数)も使用できます。

では_が既に変数(定数)として使用されている場合はどうなるでしょうか。

var lastName = "八千崎";

const string _ = "雪村";
const string KuraueHinata_last = "倉上";
const string AobaKokona_last = "青羽";
const string SaitoKaede_last = "斎藤";
const string KurosakiHonoka_last = "黒崎";

var firstName = lastName switch
{
    KuraueHinata_last => "ひなた",
    AobaKokona_last => "ここな",
    SaitoKaede_last => "かえで",
    KurosakiHonoka_last => "ほのか",
    _ => "あおい",
};

Console.Write(firstName);
// 出力結果：あおい

なんと、定数としての_とはマッチせずに、defaultのキーワードとしての_としてマッチしてしまいました。この結果、八千崎という人があおいちゃんと認識されてしまいました。これはまずい！

まぁまずないとは思いますが、_という変数(定数)はうまくマッチングできないので使用を控えましょう。個人的にはout引数でも特別な意味のあるキーワードなので_という変数などは宣言できないようにしてほしいのですが、まぁ後方互換性とかもあるのでね、仕方ないですね…。

あおいちゃんとマッチングさせたくない場合は、面倒くさがらず

var lastName = "八千崎";

const string AoiYukimura_last = "雪村";
const string KuraueHinata_last = "倉上";
const string AobaKokona_last = "青羽";
const string SaitoKaede_last = "斎藤";
const string KurosakiHonoka_last = "黒崎";

var firstName = lastName switch
{
    AoiYukimura_last => "あおい",
    KuraueHinata_last => "ひなた",
    AobaKokona_last => "ここな",
    SaitoKaede_last => "かえで",
    KurosakiHonoka_last => "ほのか",
    _ => "そんな子おらん",
};

Console.Write(firstName);
// 出力結果：そんな子おらん

としましょう。

複数`case`とのマッチは不可

ただし、複数のcaseとマッチさせることはできません。

具体的には、平日か休日かを判定したい場合、従来は

var dow_eng = DateTime.Today.DayOfWeek;
var workdayOrHoliday = "";

switch ((DayOfWeek)dow_eng)
{
    case DayOfWeek.Monday:
    case DayOfWeek.Tuesday:
    case DayOfWeek.Wednesday:
    case DayOfWeek.Thursday:
    case DayOfWeek.Friday:
        workdayOrHoliday = "平日";
        break;
    case DayOfWeek.Saturday:
    case DayOfWeek.Sunday:
        workdayOrHoliday = "休日";
        break;
    default:
        workdayOrHoliday = "エラー";
        break;
}

Console.Write(workdayOrHoliday);

この様に、月～金は平日、土・日は休日とまとめて指定できたのですが、新しいswitch式ではそれができません。

var dow_eng = DateTime.Today.DayOfWeek;
var workdayOrHoliday = (DayOfWeek)dow_eng switch
{
    DayOfWeek.Sunday  => "休日",
    DayOfWeek.Monday => "平日",
    DayOfWeek.Tuesday => "平日",
    DayOfWeek.Wednesday => "平日",
    DayOfWeek.Thursday => "平日",
    DayOfWeek.Friday => "平日",
    DayOfWeek.Saturday => "休日",
    _ => "エラー",
};

Console.Write(workdayOrHoliday);

と書くしかないんですね。これは嫌ですね。個人的には以下のような感じで書ければなと思っています。このコードは動きません。

var dow_eng = DateTime.Today.DayOfWeek;
var workdayOrHoliday = (DayOfWeek)dow_eng switch
{
    DayOfWeek.Monday | DayOfWeek.Tuesday | DayOfWeek.Wednesday | DayOfWeek.Thursday | DayOfWeek.Friday => "平日",
    DayOfWeek.Sunday | DayOfWeek.Saturday  => "休日",
    _ => "エラー",
};

Console.Write(workdayOrHoliday);

今後拡張されるかもしれないので、楽しみに待とうと思います。

ということでC# 8.0におけるswitch式の備忘録でした。

おまけ

まぁ例が悪かったのでアレなんですけど、単純に日本語の曜日を取得するだけなら

var culture_jpn = CultureInfo.GetCultureInfo("ja-JP");
var dow_jpn = DateTime.Today.ToString("dddd", culture_jpn);
Console.Write(dow_jpn);

上記でできます。実行環境が日本語カルチャの設定になっているなら、カルチャの指定すら不要です。

// 実行環境が日本カルチャの場合
var dow_jpn = DateTime.Today.ToString("dddd");
Console.Write(dow_jpn);

Unityで複数の入力方法に対応するタイピングゲームを作ろう

2021-03-06T10:10:58+09:00

はじめに

はじめまして、情報系の大学に通っているプログラム初心者の大学生です。

2年前にゼミ内で小さなゲームジャムが開催され、タイピングゲームを作ることになったのですが、ネット上で紹介されている既存のタイピングゲームの制作方法では入力方法に以下のような問題があると思いました。

1. 単語を打つ手段があらかじめ決まっている。
例 : "し"と打つときに"si"と打たなければいけなく、"shi"には対応していない。

2.単語を別々に入力できない。
例 : "ちゃ"と打つときに"ち"と"ゃ"を別々にタイプできない。

そこで今回はどんな打ち方にも対応できるタイピングゲームの制作に挑戦してみました。
この記事では仕組みとプログラムに関して紹介していきます、参考にしていただければ幸いです。

参考にした作品

今回制作したプログラムでは「寿司打」のタイピングシステムを参考にしています。

寿司打

こちらからプレイできます。

どのようなシステムかというと

ゲーム画面ではこのようにタイプする文字と入力方法が表示されています。
この状態で"し"を"si"ではなく"shi"と入力しようとすると...

"sh"と入力した時点で1つ目の"し"の入力方法が"shi"に置き換わります。
(2つ目の"し"の入力方法は変わらず表示されている。)

他にも

"ック"を入力する際に、"xtu"と"ku"で別々に入力しようとすると...

"xtu"の"x"を入力した時点で”ッ”と"ク"を別々と考えて入力方法を置き換えています。

プログラム

筆者なりに上記のシステムを再現しようとすると以下のようなプログラムになりました。

Kanji.txt

タイピングゲーム内で使う文章をそのまま入力します。
一度のタイピングで入力する長さを決めて改行してください。

別に君を求めてないけど
横にいられると思いだす。
君のドルチェ＆ガッパーナの
その香水のせいだよ。

Japanese.txt

Kanji.txtの内容を全てひらがなにして入力してください。

べつにきみをもとめてないけど
よこにいられるとおもいだす。
きみのどるちぇあんどがっぱーなの
そのこうすいのせいだよ。

KanjiFuri.txt

Kanji.txt内の文字をひらがなにした時、何文字になるかを入力してください(ひらがなの場合は1)

21212111111
211111121111
2111113111111
1122111112

Dictionary.cs

全ての入力方法を連想配列で整理しています。
下の方にある関数はKeyかValueを渡すことで紐づけられた要素を全て取り出すことができます

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Dictionary : MonoBehaviour
{
    //デフォルトの入力方法
    public readonly Dictionary dic = new Dictionary() {

        {"あ", "a"},{"い", "i"},{"う", "u"},{"え", "e"},{"お", "o"},
        {"か", "ka"},{"き", "ki"},{"く", "ku"},{"け", "ke"},{"こ", "ko"},
        {"さ", "sa"},{"し", "si"},{"す", "su"},{"せ", "se"},{"そ", "so"},
        {"た", "ta"},{"ち", "ti"},{"つ", "tu"},{"て", "te"},{"と", "to"},
        {"な", "na"},{"に", "ni"},{"ぬ", "nu"},{"ね", "ne"},{"の", "no"},
        {"は", "ha"},{"ひ", "hi"},{"ふ", "hu"},{"へ", "he"},{"ほ", "ho"},
        {"ま", "ma"},{"み", "mi"},{"む", "mu"},{"め", "me"},{"も", "mo"},
        {"や", "ya"},{"ゆ", "yu"},{"よ", "yo"},
        {"ら", "ra"},{"り", "ri"},{"る", "ru"},{"れ", "re"},{"ろ", "ro"},
        {"わ", "wa"},{"を", "wo"},{"ん", "n"},
        {"が", "ga"},{"ぎ", "gi"},{"ぐ", "gu"},{"げ", "ge"},{"ご", "go"},
        {"ざ", "za"},{"じ", "zi"},{"ず", "zu"},{"ぜ", "ze"},{"ぞ", "zo"},
        {"だ", "da"},{"ぢ", "di"},{"づ", "du"},{"で", "de"},{"ど", "do"},
        {"ば", "ba"},{"び", "bi"},{"ぶ", "bu"},{"べ", "be"},{"ぼ", "bo"},
        {"ぱ", "pa"},{"ぴ", "pi"},{"ぷ", "pu"},{"ぺ", "pe"},{"ぽ", "po"},
        {"ぁ","xa" },{"ぃ","xi" },{"ぅ","xu" },{"ぇ","xe" },{"ぉ","xo" },
        {"っ", "xtu"},
        {"ゃ","xya" },{"ゅ","xyu" },{"ょ","xyo"},
        {"きゃ","kya"},{"きぃ","kyi"},{"きゅ","kyu"},{"きぇ","kye"},{"きょ","kyo"},
        {"しゃ","sya"},{"しぃ","syi"},{"しゅ","syu"},{"しぇ","she"},{"しょ","syo"},
        {"ちゃ","tya"},{"ちぃ","tyi"},{"ちゅ","tyu"},{"ちぇ","tye"},{"ちょ","tyo"},
        {"にゃ","nya"},{"にぃ","nyi"},{"にゅ","nyu"},{"にぇ","nye"},{"にょ","nyo"},
        {"ひゃ","hya"},{"ひぃ","hyi"},{"ひゅ","hyu"},{"ひぇ","hye"},{"ひょ","hyo"},
        {"みゃ","mya"},{"みぃ","myi"},{"みゅ","myu"},{"みぇ","mye"},{"みょ","myo"},
        {"りゃ","rya"},{"りぃ","ryi"},{"りゅ","ryu"},{"りぇ","rye"},{"りょ","ryo"},
        {"ぎゃ","gya"},{"ぎぃ","gyi"},{"ぎゅ","gyu"},{"ぎぇ","gye"},{"ぎょ","gyo"},
        {"じゃ","zya"},{"じぃ","zhi"},{"じゅ","zyu"},{"じぇ","zye"},{"じょ","zyo"},
        {"ぢゃ","dya"},{"ぢぃ","dyi"},{"ぢゅ","dyu"},{"ぢぇ","dye"},{"ぢょ","dyo"},
        {"びゃ","bya"},{"びぃ","byi"},{"びゅ","byu"},{"びぇ","bye"},{"びょ","byo"},
        {"てゃ","tha"},{"てぃ","thi"},{"てゅ","thu"},{"てぇ","the"},{"てょ","tho"},
        {"うぁ","wha"},{"うぃ","whi"},{"うぇ","whe"},{"うぉ","who"},
        {"でゃ","dha"},{"でぃ","dhi"},{"でゅ","dhu"},{"でぇ","dhe"},{"でょ","dho"},
        {"くぁ","qa"},{"くぃ","qi"},{"くぇ","qe"},{"くぉ","qo"},
        {"ふぁ","fa"},{"ふぃ","fi"},{"ふぇ","fe"},{"ふぉ","fo"},
        {"ヴぁ","va"},{"ヴぃ","vi"},{"ヴ","vu"},{"ヴぇ","ve"},{"ヴぉ","vo"},
        {"ぴゃ","pya"},{"ぴぃ","pyi"},{"ぴゅ","pyu"},{"ぴぇ","pye"},{"ぴょ","pyo"},
        {"、","," },{"。","."},{"「","["},{"」","]"},
    };

    //デフォルトではない入力方法
    public readonly Dictionary Epicdic = new Dictionary()
    {
        {"ca","か" },{"ci","し" },{"cu","く" },{"ce","せ" },{"co","こ" },
        {"cha","ちゃ"},{"chi","ち"},{"chu","ちゅ"},{"che","ちぇ"},{"cho","ちょ"},
        {"cya","ちゃ"},{"cyi","ちぃ"},{"cyu","ちゅ"},{"cye","ちぇ"},{"cyo","ちょ"},
        {"fu","ふ"},
        {"ja","じゃ"},{"ji","じ"},{"ju","じゅ"},{"je","じぇ"},{"jo","じょ"},
        {"la","ぁ" },{"li","ぃ" },{"lu","ぅ" },{"le","ぇ" },{"lo","ぉ" },
        {"lya","ゃ" },{"lyu","ゅ" },{"lyo","ょ" },
        {"ltu", "っ"},
        {"nn","ん" },
        {"qu","く" },{"qyi","くぃ"},{"qye","くぇ"},
        {"sha","しゃ" },{"shi","し"},{"shu","しゅ"},{"she","しぇ"},{"sho","しょ"},
        {"tsu","つ"},
        {"yi","い"},{"ye","え"},
    };

    //渡した要素と紐づいている要素をdicから探し、リストにして返します。
    public KeyValuePair SearchdicKey(string key)
    {
        var dicpair = new KeyValuePair();

        foreach (KeyValuePair pair in dic)
        {
            if (key == pair.Key)
            {
                dicpair = pair;
            }
        }
        return dicpair;
    }

    //渡した要素と紐づいている要素をdicから探し、リストにして返します。
    public KeyValuePair SearchdicValue(string value)
    {
        var dicpair = new KeyValuePair();

        foreach (KeyValuePair pair in dic)
        {
            if (value == pair.Value)
            {
                dicpair = pair;
            }
        }
        return dicpair;
    }

     //渡した要素と紐づいている要素を両方のdicから探し、リストにして返します。
    public List> SearchTotaldicKey(string key)
    {
        var dicpair = new List>();

        foreach (KeyValuePair pair in Epicdic)
        {
            if (key == pair.Value)
            {
                dicpair.Add(new KeyValuePair(pair.Value, pair.Key));
            }
        }

        foreach (KeyValuePair pair in dic)
        {
            if (key == pair.Key)
            {
                dicpair.Add(pair);
            }
        }
        return dicpair;
    }

    //渡した要素と紐づいている要素を両方のdicから探し、リストにして返します。
    public List> SearchTotaldicValue(string value)
    {
        var dicpair = new List>();

        foreach (KeyValuePair pair in Epicdic)
        {
            if (value == pair.Value)
            {
                dicpair.Add(pair);
            }
        }

        foreach (KeyValuePair pair in dic)
        {
            if (value == pair.Key)
            {
                dicpair.Add(new KeyValuePair(pair.Value, pair.Key));
            }
        }
        return dicpair;
    }
}

SetList.cs

次にタイピングするKanjij.txtと同じ行にあるJapanese.txtとKanjiFuri.txtの文字列をSetLists()に渡し、それぞれを区分しながらListに要素を追加していきます。

・Japanese.txtは一度に入力可能でありながら、文字列が最長になるように区分し、FuriListに追加していきます。
・KanjiFuri.txtは1つの数字ごとに文字列を区分しながらKanjiFuriListに追加していきます。
・また、FuriListに要素を追加しながらDictionary.dicから入力方法を取得し、RomaListに追加していきます。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;

public class SetList : MonoBehaviour
{
    private SetText ST;
    private Dictionary Dic;

    public List RomaList;
    public List FuriList;
    public List KanjiFuriList;

    void Awake()
    {
        ST = GetComponent();
        Dic = GetComponent();
    }

    private string FuriStr = "";
    private string RomaStr = "";

    //FuriStrとRomaStrの内容をそれぞれのリストに入れて初期化する。
    private void AddList()
    {
        FuriList.Add(FuriStr);
        RomaList.Add(RomaStr);

        FuriStr = "";
        RomaStr = "";
    }

    //渡されたJapanese.txtの一行を一文字づつ仕分けるよう
    public void SetLists(string Roma , string KanjiFuri)
    {

        for(int i = 0; i < Roma.Length - 1; i++)
        {
            var chr = Roma[i].ToString();

            switch (chr)
            {
                case "っ":

                    FuriStr += chr;

                    if (i != Roma.Length - 1)
                    {
                        switch(Roma[i + 1].ToString())
                        {
                            case "あ":
                            case "い":
                            case "う":
                            case "え":
                            case "お":
                            case "な":
                            case "に":
                            case "ぬ":
                            case "ね":
                            case "の":
                            case "ん":
                                RomaStr += Dic.SearchdicKey(Roma[i + 1].ToString()).Value;
                                AddList();
                                break;

                            default:
                                RomaStr += Dic.SearchdicKey(Roma[i + 1].ToString()).Value.Substring(0,1);
                                break;
                        }
                    }
                    else
                    {
                        FuriStr += chr;

                        AddList();
                    }
                    break;

                case "ぁ":
                case "ぃ":
                case "ぅ":
                case "ぇ":
                case "ぉ":
                case "ゃ":
                case "ゅ":
                case "ょ":

                    if (i != 0 && FuriStr != "")
                    {

                        if (Dic.dic.ContainsKey(FuriStr + chr))
                        {
                            FuriStr += chr;

                            RomaStr += Dic.SearchdicKey(Roma[i - 1].ToString() + chr).Value;

                            AddList();
                        }
                        else
                        {
                            AddList();
                            FuriStr += chr;
                            RomaStr += Dic.SearchdicKey(chr).Value;
                            AddList();
                        }
                    }
                    else
                    {
                        FuriStr += chr;

                        RomaStr += Dic.SearchdicKey(chr).Value;

                        AddList();
                    }

                    break;

                case "ん":

                    FuriStr += chr;
                    RomaStr += Dic.SearchdicKey(chr).Value;

                    if (i != Roma.Length - 1)
                    {
                        switch(Roma[i + 1].ToString())
                        {
                            case "あ":
                            case "い":
                            case "う":
                            case "え":
                            case "お":
                            case "な":
                            case "に":
                            case "ぬ":
                            case "ね":
                            case "の":
                            case "ん":
                            case "や":
                            case "ゆ":
                            case "よ":
                            case "ゃ":
                            case "ゅ":
                            case "ょ":
                                RomaStr += "n";
                                break;
                        }
                    }
                    else
                    {
                        RomaStr += "n";
                    }

                    AddList();

                    break;

                default:

                    if (i != Roma.Length - 1)
                    {
                        switch (Roma[i + 1].ToString())
                        {
                            case "ぁ":
                            case "ぃ":
                            case "ぅ":
                            case "ぇ":
                            case "ぉ":
                            case "ゃ":
                            case "ゅ":
                            case "ょ":

                                FuriStr += chr;

                                break;

                            default:
                                FuriStr += chr;
                                RomaStr += Dic.SearchdicKey(chr).Value;

                                AddList();
                                break;
                        }
                    }
                    else
                    {
                        FuriStr += chr;
                        RomaStr += Dic.SearchdicKey(chr).Value;

                        AddList();
                    }


                    break;
            }
        }

        int num = 0;

        for(int i = 0; i < KanjiFuri.Length - 1; i++)
        {
            num += KanjiFuri[i] - '0';

            KanjiFuriList.Add(num);
        }
    }
}

SetText.cs

txtファイルや表示中の文字列の行数、打ち終わった字数などを管理しています。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;


public class SetText : MonoBehaviour
{
    private SetList SL;
    private TypingSystem TS;

    [SerializeField] private TextAsset Furigana = null;     //ここにKanjiFuri.txtを入れる
    [SerializeField] private TextAsset Hiragana = null;     //ここにJapanese.txtを入れる
    [SerializeField] private TextAsset Kanji = null;        //ここにKanji.txtを入れる

    [SerializeField] private List FuriList = new List();
    [SerializeField] private List HiraList = new List();
    [SerializeField] private List KanjiList = new List();

    [SerializeField] private Text RomaText = null;  //ここにKanjiFuri.txtの内容を表示するためのテキストを入れる
    [SerializeField] private Text FuriText = null;  //ここにJapanese.txtの内容を表示するためのテキストを入れる
    [SerializeField] private Text KanjiText = null; //ここにKanji.txtの内容を表示するためのテキストを入れる

    [SerializeField] private int ColumunNum = -1; //現在打っている文字列の行数、最初に+1するため最初は-1にする

    private int SetColumunNum
    {
        get { return ColumunNum; }
        set
        {
            ColumunNum = value;
            SL.SetLists(HiraList[ColumunNum],FuriList[ColumunNum]);
            KanjiProp = 0;
            ListProp = 0;
            FuriProp = 0;
            RomaProp = 0;
        }
    }

    public int Romanum { get; private set; }
    public int Furinum { get; private set; }
    public int Kanjinum { get; private set; }
    public int Listnum { get; private set; }

    //メインの文字の設定
    private int KanjiProp
    {
        get { return Kanjinum; }
        set
        {
            Kanjinum = value;
            var kanjifuristr = "";
            kanjifuristr += KanjiList[ColumunNum].Insert(Kanjinum, "");
            KanjiText.text = kanjifuristr;
        }
    }

    //フリガナの文字の設定
    private int FuriProp
    {
        get { return Furinum; }

        set
        {
            Furinum = value;
            var furistr = "";
            furistr += HiraList[ColumunNum].Insert(Furinum, "");
            FuriText.text = furistr;

            while (Furinum >= SL.KanjiFuriList[Kanjinum])
            {
                KanjiProp++;
            }
        }
    }

    //SetList.FuriListの何個目の要素を打っているか
    private int ListProp
    {
        get { return Listnum; }

        set
        {
            if(value == SL.FuriList.Count)
            {
                ResetText();
                return;
            }
            else if(value != 0)
            {
                FuriProp += SL.FuriList[Listnum].Length;
            }
            Listnum = value;
        }
    }

    //ローマ字の設定
    public int RomaProp
    {
        get { return Romanum; }
        set
        {
            Romanum = value;

            if (Romanum == SL.RomaList[Listnum].Length)
            {
                ListProp++;
                TS.ResetTypedStr();
                RomaProp = 0;
            }
            else
            {
                var romastr = "";

                for (int i = 0; i < SL.RomaList.Count; i++)
                {
                    var str = SL.RomaList[i];

                    if (i != Listnum)
                    {
                        romastr += str;
                    }
                    else
                    {
                        romastr += str.Insert(Romanum, "");
                    }
                }
                RomaText.text = romastr;
            }
        }
    }

    private void Start()
    {
        SL = GetComponent();
        TS = GetComponent();

        SetStrList(Hiragana, HiraList);
        SetStrList(Furigana, FuriList);
        SetStrList(Kanji, KanjiList);

        ResetText();

        void SetStrList(TextAsset textAsset, List list)
        {
            var array = textAsset.text.Split('\n');
            list.AddRange(array);
        }
    }

    //テキストを初期化する
    private void ResetText()
    {
        SL.FuriList.Clear();
        SL.RomaList.Clear();
        SL.KanjiFuriList.Clear();

        SetColumunNum++;
    }

}

TypingSystem.cs

txtファイルや表示中の文字列の行数、打ち終わった字数などを管理しています。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class TypingSystem : MonoBehaviour
{
    private SetList SL;
    private SetText ST;
    private Dictionary Dic;

    private string Typedstr;

    public void ResetTypedStr()
    {
        Typedstr = "";
    }

    private void Awake()
    {
        ST = GetComponent();
        SL = GetComponent();
        Dic = GetComponent();
    }

    string[] keys = { "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", 
        "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "-", ",",".","[","]"};

    //keys内にあるキーを打った時
    void Update()
    {
        foreach (string key in keys)
        {
            if (Input.GetKeyDown(key))
            {
                TypeJudge(key);
            }
        }
    }

    public void TypeJudge(string type)
    {
        //打っている途中の文字と現在打った文字をつなげる
        var JudgeStr = Typedstr + type;
        bool jud = false;

        //打った文字が n で 前の文字が nn じゃない場合
        if (type == "n" && SL.RomaList[ST.Listnum] == "n")
        {
            SL.RomaList[ST.Listnum] = "nn";
            RightEnter();
            return;
        }

        //正しく打てている場合
        if (type == SL.RomaList[ST.Listnum][ST.RomaProp].ToString())
        {
            RightEnter();
        }
        else
        {
            //Dictionaryの中のEpicDic内の文字を打とうとしている場合
            for (int i = SL.FuriList[ST.Listnum].Length; i != 0 && !jud ; i--)
            {
                var SearchStr = SL.FuriList[ST.Listnum].Substring(0,i);

                if (i != 1 && SL.FuriList[ST.Listnum][0].ToString() == "っ")
                {
                    SearchStr = SearchStr.Substring(1, SearchStr.Length-1);
                }

                var list = Dic.SearchTotaldicKey(SearchStr);

                foreach (var d in list)
                {
                    var MatchStr = "";

                    if (i != 1 && SL.FuriList[ST.Listnum][0].ToString() == "っ")
                    {
                        MatchStr += d.Value.Substring(0, 1);
                    }

                    if (JudgeStr.Length <= MatchStr.Length + d.Value.Length && !jud)
                    {

                        MatchStr += d.Value;

                        if (JudgeStr == MatchStr.Substring(0, JudgeStr.Length))
                        {
                            //print(MatchStr + "で見つかりました");
                            TypeMatch(i , MatchStr);
                        }
                    }
                }
            }

            //該当した文字が無い場合(ミスタイプしている場合)
            if(!jud)
            {
                MissEnter();
            }

        }

        //EpicDic内にある文字が正しく打てている時に呼び出される
        //打った文字とまだ打っていない文字を切り分ける作業をする
        void TypeMatch(int num, string MatchStr)
        {
            jud = true;
            var Furistr = SL.FuriList[ST.Listnum];
            SL.FuriList[ST.Listnum] = Furistr.Substring(0, num);
            SL.RomaList[ST.Listnum] = MatchStr;

            if(Furistr.Length != num)
            {
                SL.FuriList.Insert(ST.Listnum + 1, Furistr.Substring(num));
                SL.RomaList.Insert(ST.Listnum + 1, Dic.SearchdicKey(SL.FuriList[ST.Listnum + 1]).Value);
            }

            Typedstr = JudgeStr;
            RightEnter();
        }

        //ミスタイプしたとき
        void MissEnter()
        {
            print("ミスしました！");
        }

        //正しく打てているとき
        void RightEnter()
        {
            Typedstr = JudgeStr;
            ST.Romanum++;
        }
    }
}

実際に動かしてみる

上にあるプログラムを全て同じオブジェクトにアタッチし、以下の画像のように設定すると動きます。

完成した作品

そしてこのプログラムを組み込んで実際に完成した作品がこちらになります。

ケロツグ -雨乞いタイピング-

Webからのプレイはこちらから。
プロジェクトのダウンロードはこちらから

芥川龍之介の「蛙」の文をひたすら打つタイピングゲームです。
文字を打つたびに蛙が増えていき、正確なタイピングを続けると制限時間が増えたりします。

最後に

作るのは苦戦しましたが内容は結構シンプルな構造になっていると思います。
この方法で作っていると対応していないキーが出てくると思います。
見つけた場合はDisctionary.csの方に書き足して頂けると対応されると思います。

最後まで読んでいただきありがとうございました。

【C#】「単純なusingステートメント」の違和感

2021-03-02T20:29:59+09:00

usingは外部リソースを確実に解放するために用いる。

たとえば、

using (var sw = new StringWriter(filePath, append: true, Encoding.UTF8))
{
    sw.Write(hoge);
}

と書けば、スコープを抜けた時点でファイルが確実に解放される。いちいちCloseとかDisposeとかしなくて済むのだ。これは素晴らしい。

処理が単一ステートメントであれば{}は省略できるので、

using (var sw = new StringWriter(filePath, append: true, Encoding.UTF8))
    sw.Write(hoge);

このように書ける。これも全く同じ意味で、ifの{}を省略しているのと変わらない。ので、今までこう書いていたが、C#8.0では以下のようにメッセージが表示される。

IDE0063：'using'ステートメントは単純にできます

推奨の修正を適用すると、

using (var sw = new StringWriter(filePath, append: true, Encoding.UTF8));
sw.Write(hoge);

となる。これも動くんだけど違和感がすごい。なんというか、usingの後に{}があればスコープはそこに限定されるし、なければ次の単一処理がスコープになっているとはっきりわかる。

でもこれ、

using (var sw = new StringWriter(filePath, append: true, Encoding.UTF8));
sw.Write(hoge);
sw.Write(fuga);

ってかけるんだよね。で、fugaも書き込まれるんだよね。じゃあスコープはいつまで有効なの？というと、その変数の範囲らしい。

個人的には使わなくなったらとっととDisposeしないと気持ち悪いので、IDEの警告を抑制して無視して、従来通り{}を必要に応じて使ってスコープを明記することにした。もっとも、そこだけメソッドに切り出して単純なusingを使うのが一番スマートなのかもしれないが。

【C#】コメントに書くこと、書かないこと

2021-01-13T20:55:23+09:00

※C#としているがC#以外でも同じで、サンプルコードをC#で書いているのでタイトルにC#とつけた。

プログラミングを行う上で、コメントの重要性は大きい。適切なコメントを書けばコードを読む人の助けになる。逆に、どうでもいいコメントや嘘のコメントを書けばそれは悪影響をもたらす。

コメントに関しては宗教のようなものなので初めに私のポリシーを明記しておく。この記事の内容もこれに沿って展開する。

コードを読んだら秒でわかることはコメントに書かない
コードを読んだらわかるが読むのに時間がかかりそうな時は書く
なぜこのようなロジックになっているかを書く
拡張・修正する際に、罠になりそうな箇所の警告を書く
コメントで説明するくらいなら命名を見直す
変更前のソースをコメントアウトして残さない（論外）

この記事の内容はあくまで私が考えていることの表明であって、「私の意見が絶対的に正しい」とか「コメントはこう書かれるべきである」という趣旨の内容ではない。念のため書いておく。

コードを読んだら秒でわかるようなことはコメントに書かない

正確に言うと、書く必要がない。なにせ読んだら秒でわかるのだから。

極端な例だが、以下のようなコメントは不要だ。

// 〇〇さん（xx）
var nameAndAge = $"{name}さん（{age}）";

これは、変数を「〇〇さん（xx）」の形に整形しているが、そんなもん見たらわかるのである。

見たらわかることをいちいちコメントに書く必要はない。何故か？

それは、ソースを修正する時にコメントも修正する必要が出てくるからだ。

上記コードを以下のように修正したとしよう。

// 〇〇さん（xx）
var nameAndAge = $"{name}さん（{age}歳）";

コードは修正したが、コメントの修正を忘れたとする。するとどうなるか。

ソースを見ると「〇〇さん（xx歳）」となっているが、コメントは「〇〇さん（xx）」となっている。これを見た人は、「どっちが正しい仕様なんだろう？」と頭を悩ませるのである。そして仕様を確認するという手間が発生するし、コメントを修正する（あるいは修正を指示する）という手間も発生することだろう。

書いていなければ「ふーん、『〇〇さん（xx歳）』の形式ね。」とスムーズに読めるのに、コメントがコードの内容と違っているばかりに余計な手間がかかる。これは完全に悪である。

「いやいや、普通はコードと一緒にコメントも修正するでしょ」と言う人もいるかもしれないが、そういう普通の人と一緒に働いてみたい。特にコード変更に対して充分な時間が与えられないことは往々にしてあり、急いで修正、テスト通るかのチェックをしてレビュアーに投げるというものだろうが、経験上ほとんどのレビュアーは差異が発生している部分しかチェックしない。

コメントが実装と違っていてもテストは通るし、人の目のチェックも通る時は通るのだ。だからこそ、コメントは常に正確に書いていなければそもそも書く意味がないのだ。コードを変えたならコメントもそれに合わせて変えなければならないのだ。

でも人間はそんな完璧じゃないから絶対にどこかで修正漏れが発生する。だったら初めから「コードを読んだら秒でわかる」ような箇所のコメントは不要なのだ。

コードを読んだらわかるが読むのに時間がかかりそうな時は書く

以下のようなコード。

public static List Nabeatsu()
{
    var nabe = new List();

    foreach (var n in Enumerable.Range(1, 40))
        if ((n % 3 == 0) || $"{n}".Contains("3"))
            nabe.Add("アホ");
        else
            nabe.Add($"{n}");

    return nabe;   
}

これは、「1から40までの自然数のうち、3の倍数または3のつく数字の時は「アホ」を、そうでない時はその数字を文字列型のListに入れて返す」という挙動のNabeatsuというメソッドである。

上記のことは、コードを読めば分かるが意図を正確に把握するにはを全て読まなければならない。

こういうコードは処理が簡単に書いてあれば便利だ。メソッドであればXMLコメントとして残すべきだ。

Visual Studioを使っているならば、メソッドの上に///と入力するだけでXMLコメントの雛形が自動で作成される。

/// 
/// 
/// 
/// 
public static List Nabeatsu()
{
    var nabe = new List();

    foreach (var n in Enumerable.Range(1, 40))
        if ((n % 3 == 0) ** $"{n}".Contains("3"))
            nabe.Add("アホ");
        else
            nabe.Add($"{n}");

    return nabe;   
}

あとは、コメントを書いていくだけだ。

/// 
/// 1から40までの自然数のうち、3の倍数または3のつく数字の時は「アホ」を、そうでない時はその数字を文字列型のListに入れて返す
/// 
/// そのまま使えるナベアツリスト
public static List Nabeatsu()
{
    var nabe = new List();

    foreach (var n in Enumerable.Range(1, 40))
        if ((n % 3 == 0) ** $"{n}".Contains("3"))
            nabe.Add("アホ");
        else
            nabe.Add($"{n}");

    return nabe;   
}

このようにXMLコメントを書いておくと、

のように、呼び出し元でメソッド名をマウスオーバーすると参照できるようになる。

なぜこのようなロジックになっているかを書く

コードを読んでいると、「ここはなんでこう書いてるの？」と思うことがある。その疑問に先回りして「なぜか」が書いてあるコメントは良いコメントだと思う。

やや乱暴な例だが、例えば以下のようなコード。

user.UpdatePasswordTo(plainPassword);

これは恐らく、「パスワードを引数の文字列で更新している」という処理だろう。

しかしplainPasswordは見るからに平文のパスワードだ。こんなもんそのまま更新する訳にはいかない。

このコード、実はUpdatePasswordTo内部で引数の文字列はハッシュ化するという処理が実行されることになっている。だからここは別に平文で渡しても問題ないのだ。

だがそんなことはどこにも書いてない。UpdatePasswordToの実装を見るまでは分からないのである。

そこで、

user.UpdatePasswordTo(plainPassword);   // 中でハッシュ化するから平文でOK

というコメントがあったとしたらどうだろうか。それなら問題ないな、と疑問がすぐ解決するのではないだろうか。

もちろん、そのコメントが嘘であってはいけない（つまり本当は中でハッシュ化などしていない）が、こういうコメントはそれが事実である限りとても役に立ち、コードリーディングを助けるものになる。

拡張・修正する際に、罠になりそうな箇所の警告を書く

これも余りいい例が思い浮かばないのでちょっと強引な例だが書いてみる。

あるシステムがあり、利用者には個別のuserIdを自分で設定してもらう。userIdは"@"以外の文字列で任意に設定できるが、実は使用しているライブラリのバグで"@"から始まる文字列を登録しようとすると実行時エラーになる。が、現在の仕様だとそもそも"@"は入ってこないため特に問題はなかったとする。

ここで"@"をIDに含めたいというユーザーの要望により、ユーザーIDに"@"を含められるように仕様変更することになった。"agasahakase"というユーザーがカッコつけて"@g@s@h@k@se"というIDにしたいと言い出したのだ。

仕様変更しリリースすると、"agasahakase"さんは"@g@s@h@k@se"にIDを変更していた。別のユーザーで、TwitterライクなIDにしたいと思い"apashoni"から"@apashoni"に変更しようとしたユーザーは更新に失敗してしまった。

急いで原因を調査するが、何も分からない。コードを書いた人は既に転職しており誰も原因がわからない。三日三晩寝ずに調べて、とうとう"@"で始まる文字列はIDに設定できないということが判明した。

もしここで、

user.UpdateIdTo(newId); // 現行仕様では関係ないが、ライブラリのバグで"@"で始まるIDは登録できない

などと一言添えてあればそれを見越したリリース案内が出来たのである。

まぁ上記のはかなり強引な一例であり実際にここまで書くかは議論の分かれるところかもしれないが、「罠になりそうあ箇所の警告を書く」とは上記のような話だ。

現行仕様や近々に何かに影響する訳ではないが、将来的に役立つかもしれないことを書いておくのも良い。

繰り返すが上記はかなり強引な例えだ（いい例が思いつかなかった）。

コメントで説明するくらいなら命名を見直す

【C#】命名って大事だねという記事でも書いたが、不足情報を補うくらいなら命名やロジックで直感的に説明しコメントは書かないという方がよほど親切だ。理由は前述した通り、コメントもメンテナンスが必要になるため。

例えば以下のようなコード。

// 単価
decimal price = 100;

// 単位はmm
decimal height = 1700;

これらは

decimal unitPrice = 100;

decimal height_mm = 1700;

という命名にすれば、単価だということや単位がmmだということは一目瞭然だ。コメントを書く前に、まずこれらができないか試すべきだと個人的には思う。

変更前のソースをコメントアウトして残さない（論外）

これ、最近のエンジニアさんはおとぎ話くらいに思うのだろうか…？

これらは、バージョン管理ソフトが普及していなかった頃の名残だ（と思う）。昔はバージョン管理ソフトなんていう便利なものはなかったので、こうやって修正前のコードを残しておく必要があった。

しかし現在はだいたいどのチームでもgitやSubVersionなんかを使ってバージョン履歴管理やソースコードの共有などをしているのであり、現代ではほとんど不要なハックと言える。読んでいて邪魔になるだけだし、そもそもコメントアウトを外してもまともに動作しない。

残念ながら未だにこういうコードは見かけるし、こういう風にコメントを残す人もいる。特に大昔からコード書いている人なんかは、よくこういうコメントアウトをしていらっしゃる。恐らくバージョン管理ソフトの使い方などを分かっていないんだと思うが、だったら勉強とかちゃんとしてほしいなと正直思う。勉強できない古のエンジニアはとっとと解雇して私の給料増やしてちょと思うのだがなかなかそうもいかないので難しいところだ。

まとめ

以上が、私がコメントを書くときに気を付けているような内容だ。ここには書いていないが意識していることも多分あると思う。

繰り返しになるが、あくまで私個人の考えで合ってこれが正しいという訳ではないが、まぁ別にそこまで変なことを書いているつもりもないので参考になるところをつまみ食いで参考にしてもらえればいいなと思う。

【C#】DRYとOAOO

2021-01-11T21:48:56+09:00

DRY原則とは

知っている人も多いと思うが、DRY原則というものがある。

Don't Repeat Yourselfの頭文字をとった言葉で、簡単に言うと「同じことを繰り返すな」という意味。

サンプルコード

例を出してみる。

public class Person
{
    public string FirstName { set; get; } = "";
    public string LastName { set; get; } = "";
    public string FullName { set; get; } = "";
}

上記のようなPersonクラスのインスタンスを作成するとしよう。

var haruki = new Person();
haruki.FirlstName = "Haruki";
haruki.LastName = "Yachizaki";
haruki.FullName = "Yachizaki Haruki";

Console.Write(haruki.FullName);
// 結果 -> Yachizaki Haruki

FullNameを出力すると、"Yachizaki Haruki"となる。

上記のクラスには問題がある。

それは、FirstNameとLastNameを設定して、FullNameの設定が漏れていた場合に、FullNameが出力されないという問題だ。

var haruki = new Person();
haruki.FirstName = "Haruki";
haruki.LastName = "Yachizaki";
// haruki.FullName の設定を忘れている

Console.Write(haruki.FullName);
// 結果 -> ""(空白)
// PersonクラスのFullNameのデフォルト値が表示される

設定されるべき値を設定していなかったのだから当然の挙動だが、そもそも一般的にFullNameはFirstNameとLastNameさえ分れば求められるにも関わらず、個別に設定しなければならない方がおかしいと言えるだろう。FullNameの設定を繰り返しているとも言える。

そこで、FullNameを修正し、以下のようにしてみる。

public class Person
{
    public string FirstName { set; get; } = "";
    public string LastName { set; get; } = "";
    public string FullName => $"{LastName} {FirstName}";
}

FullNameは個別に設定するのではなく、FirstNameとLastNameを組み合わせて返すように変更する。

すると、

var haruki = new Person();
haruki.FirstName = "Haruki";
haruki.LastName = "Yachizaki";
// haruki.FullName は設定しない(setterを持たないのでそもそもできない)

Console.Write(haruki.FullName);
// 結果 -> Yachizaki Haruki

となる。

他のプロパティから求められるプロパティは個別に用意しないという考え方では、DB設計などでも用いられる。DB設計においては、主にパフォーマンスの面から冗長なフィールドを用意することもあるが（価格と税率と税込み価格を持っておくなど）、プログラミングのソースコードにおいてはそこまで意識することは少ないと言えると思う（※ぱっと例が思いつかないが、冗長な実装をした方がいいケースもきっとあると思う）。

プロパティが増えれば増えるほど管理しなければいけない情報が増え、バグの元になる。

メリット・デメリット

メリット

テストの箇所を集約できる
- 複数個所に書いていればその分テストが必要だが、一か所であればそれだけでカバーできる
ロジックの改善や仕様変更の際に修正の手間が激減する
- トレースログを仕込む時などに便利

デメリット

変更が呼び出し箇所全てに反映されるため、影響範囲を把握しておく必要がある

OAOO

DRY原則とよく似た考え方に、OAOO(Once And Only Once：ただ一度だけ書く)がある。

例を示す。下記のようなコードがあるとする。

var message1 = "あけましておめでとうございます";
var message2 = "今年もよろしくお願いします。";

var newMessage1 = "";
var newMessage2 = ""+

const string Dot = "。";

if (message1.EndsWith(Dot))
    newMessage1 = message1;
else
    newMessage1 = message1 + Dot;

if (message2.EndsWith(Dot))
    newMessage2 = message2;
else
    newMessage2 = message2 + Dot;

Console.Write(newMessage1 + newMessage2);
// 結果 -> あけましておめでとうございます。今年もよろしくお願いします。

上記コードは2つのメッセージを連結して出力するが、各メッセージが読点(。)で終わっていなければ付け足した後に連結するということをしている。

この、「読点がなければ付け足す」という処理はmessage1に対して行うかmessage2に対して行うかだけの違いだが、2回に渡って書かれている。

これにOAOOを当てはめると、以下のようにできる。

// 以下のメソッドを用意
static string AppendDotIfNeeded(string message)
{
    const string Dot = "。";

    // nullチェックは省略
    if (message.EndsWith(Dot))
        return message;
    else
        return message + Dot;
}

// メソッドを用意すると以下のように書ける
var message1 = "あけましておめでとうございます";
var message2 = "今年もよろしくお願いします。";

var message1EndsWithDot = AppendDotIfNeeded(message1);
var message2EndsWithDot = AppendDotIfNeeded(message2);

Console.Write(newMessage1 + newMessage2);
// 結果 -> あけましておめでとうございます。今年もよろしくお願いします。

「読点がなければ付け足す」という処理をメソッドに抽出したことで流用できるようになった。

DRYはシステム全体での重複を（排除すべきところでは）排除しようという考え方、OAOOはあくまでソースコード上において、同じような内容はまとめようという考え方だと理解している。

【C#】命名って大事だね

2021-01-09T22:31:27+09:00

命名って大事だよね、ということはコードを書く人であればだいたい同意していただけると思う。

というかコードを書かない人も「memo.txt」と「〇月〇日までに買う予定リスト.txt」だったら、ファイルの内容が同じでも後者の方が圧倒的にわかりやすいとは思っていただけると思う。

毎度毎度弊社の困ったちゃんのことを書くのは忍びないが、だけど書くが、困ったちゃんははっきり言って命名がヘタクソである。私も別に命名に自信ニキという訳ではないが、まぁ困ったちゃんよりは上手く命名していると思うし、自分の命名で困ったこともあまりないので書いてみる。

以降、サンプルコードにC#を用いるが別にどの言語でも共通する話だと思う。難しいことは書かないのでC#がわからなくてもだいたい読めると思う。

なぜ命名が大事か

簡潔に言うと情報量の違いだと思う。

極端な例だが、次のような変数宣言があるとする。

decimal price = 100;

priceは価格・値段といった意味だが、はっきり言ってpriceという文字だけでこれが何に使われるのか正確にはわからない。

具体的には以下のような情報が欠けている。

単価？小計？合計？
税込み？税抜き？
（キャンペーンなどがある場合）割引適用前？適用後？
単位は日本円？ドル？

こういった情報はできるだけ変数名に明示的に盛り込むべきだと考える。

// 単価なら
decimal unitPrice = 100;

// 小計なら
decimal subTotal = 100;

// 合計なら
decimal total = 100;

// 税込みなら
decimal taxIncludedPrice = 100;

// 税抜きなら
decimal taxExcludedPrice = 100;

// 割引適用前なら
decimal undiscountedPrice = 100;    // または originalPrice

// 割引適用後なら
decimal discountedPrice = 100;

// 単位が縁
decimal price_yen = 100;

// 単位がドル
decimal price_dol = 100;

といった具合に変数名に情報量を持たせることで可読性を上げることができる。

この考え方は一部、アプリケーションハンガリアンといわれる考え方と一致する。

たとえば、

decimal total = price_yen + price_dol;

のようなコードはドルと日本円を加算しており、明らかに間違いだということが見ただけで分る。正しくは

// ドルは円に換算して可算する
decimal total = price_yen + ConvertToYen(price_dol);

としなければならないと判断できる。これが命名が持つ強力なメリットであり、命名にこだわる理由である。

こういった考え方が活きる場面はたくさんある。

// パスワード
string password = "XXXXX";
// パスワードを更新
user.updatePassword(password);

これだと、passwordで更新しているが、うっかりpasswordが平文のままだったら平文がそのまま登録されているかもしれない。

もし変数名をplainPasswordなどとしていれば平文のパスワードということが見ただけで分かるので、登録前にハッシュ化させる必要があると気づけるだろう。

// 平文のパスワード
string plainPassword = "XXXXX";
// ハッシュ
string hashedPassword = plainPassword.Hash();
// ハッシュ化されたパスワードで更新
user.updatePassword(hashedPassword);

また、コーディングミスにより

// 誤って平文で更新するコードになっている
user.updatePassword(plainPassword);

と書いてしまっていたとしても、「平文で更新するっておかしいよね？」と気づくきっかけになるハズだ。

このような「これは税計算必要なの？」「これは平文？」などの情報はよくコードを読めば分かることではある。だがその「よくコードを読む」作業を意識から切り離して、本来考えたいアルゴリズムや可読性などに集中できるのが大事だ。そしてそれは命名の工夫をするだけで改善できることでもある。

汎用性の高い接頭辞や接尾辞もあるので、それらはいつでも使えるようになっておくとベストだ。

xxxFlgという変数名

真偽値などでxxxFlgなどという命名をしているのをたまに見かけるが、これもあまり優しくないと思う。

例えばdeleteFlgという変数名があるとする。これは以下のように様々な解釈が可能である。

削除済みのデータであることを示すフラグ
削除できる状態のデータであることを示すフラグ
削除しなければならないデータを示すフラグ
削除される予定のデータであることを示すフラグ

などだ。deleteとしか書かれていないのだから如何様にも解釈できる。trueで削除済みなのかfalseで削除済みなのかも、変数名からは分からない。個人開発ならともかく、チームで開発するプロジェクトにおいて「そんなつもりで命名した訳じゃない」「普通に考えたらこう」なんていうのは通用しない。何故ならそのコードは自分だけではなく、他の誰かが読んだり修正したりするかもしれないからだ。個人開発だとしても、何日も経って忘れたころに見直すこともあるだろう。だからこそ、直感的に分かりやすい命名をする必要がある。

真偽値の命名にはis, has, can（もしくはis～able）, shouldなどを使うと可読性が上がると言われている。それらはY/N質問として読めるし、意味のはき違えようがないからだ。

// 削除済み
bool isDeleted = true;

// 削除できる
bool canDelete = true;
bool isDeletable = true;

// 削除しなければならない
bool shouldDelete = true;

これだと、isDeletedは「削除済みか？」に対してtrue(削除済み)かfalse(削除済みではない)とハッキリするのである。isDeletedという変数名で「trueだから『削除しなければならない』ってことだな！」「trueだから未削除なんだな！」と解釈する人はまずいないだろう。それは考え方とかじゃなくて英語力の問題だから…。

コメントで補えるのでは

命名をシンプルにしてコメントで補えるのでは、と思うかもしれない。確かにそういう手もあるが、個人的には望ましくないと考える。なぜか。

それはコメントはメンテしないといけないからだ。

// 税抜き価格
decimal price = 100;

というコメントをつけたコードがあったとする。これが税込み価格を反映するという修正が必要になった場合、

// 税抜き価格
decimal price = 110;

と修正するだけでなく、コメントも

// 税込み価格
decimal price = 110;

と直さなければならなくなる。修正の工数がしっかり確保されており、コメントも含めてレビューされるような環境であればまだいいかもしれないが、多くの場合修正レビューはテストが通るかどうかと差分の比較であり、コメントは忘れ去られる。動作は自動テストが保障してくれるかもしれないが、コメントが合っているかどうかは人の目でみないと分からない。

もしコメントのメンテを怠ると、そのコメントは嘘になる。コメントに嘘が書いてあるくらいなら、コメントがない方が100倍ましだ。そうやって嘘のコメントが積み重なって保守不可能な過去の遺産になっていく。コメントで意味を補足するくらいなら、taxExcludedPriceやtaxIncludedPriceなどの具体的な意味を持った命名をした方が良い。

システムハンガリアンは…

前述した「アプリケーションハンガリアン」とは別に「システムハンガリアン」という考え方もあるが、これは現代ではもはや推奨されていないシーンの方が多い。以前は私も使っていたが、最近はまず使わないようになった。

string sName = "あぱしょに";
int nAge = 27;

システムハンガリアンは、string型ならsやstr、int型ならnやintのように、各変数の型を識別できる接頭辞を入れるというものだ。

これも同様にコードを見ただけでエラーが分かるようになるというハックの一つだが、静的型付け言語ではたとえば

string sName = "あぱしょに";
int nAge = 27;
int hoge = nAge * sName; // エラー

などと間違えて書いても

のように教えてくれるので、変数を見ただけで型の不一致がわかるというメリットは少ない。動的型付け言語であれば違うと思うが…。

また、システムハンガリアンは型を変更した際に変数名も修正しなければならない（そうでないとシステムハンガリアンのメリットが正しく発揮されない）。たとえばnUserIdをint型からstring型に変更した場合は、型だけでなく変数名もsUserIdと変更しなければならず、これは大変な手間である。

そういった理由で、システムハンガリアンは現代ではほとんど見られなくなった（少なくとも私の観測範囲では）。これからも私が積極的に使うことはないだろう。昔の案件の修正などで既にコーディングスタイルが指定されていれば従うが。

英語にこだわらなくていい

個人的には無理して英語にこだわって意味不明な変数名になるよりは、別にローマ字でもいいから意味が分かるよう正確に命名してほしいと思っている。

また、英語に自信がなければcodicやDeepLなど便利なサービスもあるので、それらも活用したい。特に前者はネーミングに特化しているだけでなく、camelCaseやsnake_case、PascalCaseなど自由にスタイルをカスタマイズできる。私はこれらのサービスで色んな語を知った。

【C#】ワンライナーで書ける式形式メンバー

2021-01-08T21:12:03+09:00

式形式メンバー

まずは下記のコードをご覧ください。

public static bool IsNullOrEmpty(this string text)
{
    return string.IsNullOrEmpty(text);
}

上記は【C#】拡張メソッドという記事で例示した、string.IsNullOrEmpty()を扱いやすくした拡張メソッドです。

var text = "";

// これが
Cnosole.Write(string.IsNullOrEmpty(text));

// こう書ける
Console.Write(text.IsNullOrEmpty());

という方法を実現する拡張メソッドですね。

このコード、string.IsNullOrEmpty()をreturnしているだけなのに{}で括ってあげるのがなんか嫌じゃないですか？

だって、foreachもifも、続く処理が単文(単一ステートメント)であれば{}は不要ですよね。

// これは
foreach (var n in Enumerable.Range(1, 20))
{
    Console.Write(n);
}

// こう書ける
foreach (var n in Enumerable.Range(1, 20))
    Console.Write(n);

// これは
if ((n == 3) || ($"{n}".Contains(3)))
{
    Console.Write("アホ");
}

// こう書ける
if ((n == 3) || ($"{n}".Contains(3)))
    Console.Write("アホ");

組み合わせて

// これを
foreach (var n in Enumerable.Range(1, 20))
{
    if ((n == 3) || ($"{n}".Contains(3)))
    {
        Console.Write("アホ");
    }
}

// こう書ける
foreach (var n in Enumerable.Range(1, 20))
    if ((n == 3) || ($"{n}".Contains(3)))
        Console.Write("アホ");

こうも書ける訳です。余計な{}がなくてスッキリしていますよね。特に先人の残したネスト地獄のコードを読んでいると、{}なんて見るのも嫌じゃないですか。

だから、メソッドでも{}なしで書きたいですよね？ですよね？

メソッドも、{}を省略して書けるケースがあります。

// これは
public static bool IsNullOrEmpty(this string text)
{
    return string.IsNullOrEmpty(text);
}

// こう書ける
public static bool IsNullOrEmpty(this string text) => string.IsNullOrEmpty(text);

どうでしょうか？{}が減っただけですが、かなりスッキリしましたよね。

こういう記法ができる式形式メンバーはC#6.0で実装され、C#7.0で拡張されました。

条件

式形式メンバーは、単一ステートメントで記載されているメソッドやプロパティに使用できます。

なので、たとえば以下のようなメソッドは、式形式メンバーは使用できません。

// アホ毛・パーカー・ショートヘア・ニーソのいずれか2つ以上を満たせばボーイッシュとする
public static bool IsBoyish(this GirlModel girl)
{
    var boyishibility = 0;

    // アホ毛か
    if (girl.HasAhoge)
        boyishibility++;

    // パーカーか
    if (girl.IsWearingHoodie)
        boyishibility++;

    // ショートヘアか
    if (girl.HasShortHair)
        boyishibility++;

    // ニーソか
    if (girl.IsWearingKneeSocks)
        boyishibility++;

    // 判定
    return (boyishibility >= 2);
}

ですが、たとえばボーイッシュがより広く浸透した世界で、アホ毛・パーカー・ショートヘア・ニーソのいずれか一つでも満たせばボーイッシュといえるようになった場合は、下記のように書けます。

public static bool IsBoyish(this GirlModel girl) => (girl.HasAhoge || girl.IsWearingHoodie || girl.HasShortHair || girl.IsWearingKneeSocks);

ちなみにアホ毛・パーカー・ショートヘア・ニーソは私のHN「あぱしょに」の名前の由来です(小声)

書き方

書き方は、{}の代わりに=>を使用して、returnを省略するという記法になります。

// これは×
// returnは書かない
public static bool IsNullOrEmpty(this string text) => return string.IsNullOrEmpty(text);

この記法は、続くステートメントをreturnしますよ、ということをコンパイラに通知しているんですね。なので明示的にreturnは書けません。

{}を省略できると書きましたがどちらかというと副産物的なメリットで、本来はreturnを省略するための記法ということになります。

戻り値を返さないメソッドにも使える

戻り値を返さないメソッドに対しても、単一ステートメントのメソッドであれば式形式メンバーを使用できます。

// これは
public static void WriteToConsole(this object logMessage)
{
    Console.Write(logMessage);
}

// こう書ける
public static void WriteToConsole(this object logMessage) => Console.Write(logMessage);

これらのメソッドはもともと、ふつうはreturnを省略するかと思いますが式形式メンバーでも同様にreturnは書きません。

式形式メンバーは便利か

個人的には、使えるところでは積極的に使っています。タイプ量が減るのも良いですが、ワンライナーで書けるのがやっぱり楽です。慣れてしまえば読む時でもメリットがあると思います。

ただし、実際の処理が改行&インデントされていれば、それはそれで読みやすいということもあると思います。その辺りは個人の感覚によりけりですが、こういう記法があるということを知っているだけでも訳に立つと思います。

参考

C# の歴史
 式形式のメンバー (C# プログラミングガイド)

【C#】varの使い方、メリットとデメリット

2021-01-06T20:08:06+09:00

使い方

C#では変数宣言時、型を書く必要がある。

string text = "あいうえお";

この時、varキーワードを使用することで右辺から型を推論させて変数宣言を行える。

var text = "あいうえお";

// textはstring型となる

Visual Studioで確認すると、string型となっていることがわかる。

varは右辺から型を判別している。そのため、下記のコードはコンパイルエラーとなる。

var text = null;

// nullの型を判別できないためコンパイルエラーとなる

もしstring型のnullをvarを使って宣言する場合、下記のように書かなければならない。

var text = (string)null;

この記法だと一応宣言はできるが、あまり型推論のメリットがない。（後述するようにメリットがない訳ではない）

メリット

varを使うと次のメリットがある。

複雑な型名を書かなくても良い
型が変更されたときに書き直さなくても良い
コードが読みやすくなる

順番に解説する。

複雑な型名を書かなくても良い

たとえばDictionary, string>, Dictionary, Dictionary>>を返すNegativeMethodという関数があるとしよう。

これもvarを使うと型名を書かなくてよい。

public static Dictionary, string>, Dictionary, Dictionary>> NegativeMethod()
{
    Dictionary, string>, Dictionary, Dictionary>> something = new Dictionary, string>, Dictionary, Dictionary>>();

    // ～複雑な処理

    return something;
}

Dictionary, string>, Dictionary, Dictionary>> result = NegativeMethod();

上記のようなコードが、下記のように書ける。

public static Dictionary, string>, Dictionary, Dictionary>> NegativeMethod()
{
    var something = new Dictionary, string>, Dictionary, Dictionary>>();

    // ～複雑な処理

    return something;
}

var result = NegativeMethod();

型が明確になっている場合は、複雑な型を書かなくて良くなる。TupleやDictionaryは複雑になる場合もあるが、それをいちいち書かなくても良いメリットとなる。なお、後述するがこういう使い方にはデメリットもあるので注意。

型が変更されたときに書き直さなくても良い

たとえばuserIdはint型だったが、アルファベットを含めるという仕様変更にあたりstring型に変更することになったとする。

ここで、下記のように修正する必要がある。

// GenerateUserIdはintを返す
int userId = GenerateUserId();

// ▲これを下記のように変更する▼

// GenerateUserIdはstringを返すようになった
string userId = GenerateUserId();

数か所であれば問題ないがもし何十箇所・何百箇所も記載してあればそれらを漏れなく修正する必要がある。

一括で置換するという方法もない訳ではないが、対象が漏れなく置換されたか、本来修正範囲外のコードが変更されていないかなどの差分確認の作業が結局発生する。

初めからvarで記載しておけば型が変更されてもコードの修正が必要なく、修正後にテストを走らせればそれだけで済む。

// GenerateUserIdがintからstringになっても、ここは修正する必要がない
var userId = GenerateUserId();

コードが読みやすくなる

ここは感覚的な問題だが例を示す。

下記のようなコードがあるとする。

int userId = GenerateUserId();
string firstName = "";
string lastName = "";
DateTime birthday = new DateTime(1990, 1, 1);

これはvarを使用すると次のように書ける。

var userId = GenerateUserId();
var firstName = "";
var lastName = "";
var birthday = new DateTime(1990, 1, 1);

こうすると型の部分が全てvarになり、変数名のインデントが揃って読みやすくなる…気がする。少なくとも私は、バラバラに型を書いているよりvarで揃っていた方が読みやすい。

デメリット

上記のようにとてもメリットの大きなvarだが、デメリットとなるケースも存在する。

それは、人間が容易に型を推論できない場合だ。

var firstName = GetFirstName(userId);

上記の場合、おそらくfirstNameはstring型になるだろうという想像が出来る。varを使用するのが相応しいケースの一つだ。

しかし下記の場合はどうだろう？

var idAndNames = GetIdAndNames();

GetIdAndNamesはおそらくidとnameを（おそらくペアで）取得するメソッドだと予想はできるが、どういう型になっているかは実装部分を見ないと判定できない。DictionaryかもしれないしList>かもしれない。独自クラスのコレクションになっている可能性もある。

varを使用したらGetIdAndNamesがどのような型を返すとしても寛容に受け入れてしまう反面、型が分かりにくくなるというデメリットもある。(上記の例は関数名などのネーミングの問題もあるが)

Visual StudioなどのIDE上で読むのであれば、変数名にマウスオーバーしたら型が分かるが、バージョン管理ソフトの履歴などの画面では当然そのような機能がないため読みづらい。型が分かりにくい場合は型を明記するが、コメントを添えておくと良いだろう。

コメントは後で型が変わった時などにメンテしなければならないので、明記する方が個人的には良いと思う。型を明記していればコンパイルエラーなどで検知できるので修正漏れを防ぐ助けにもなる。

// varを使わず型を明記する場合
Dictionary = GetIdAndNames();

// コメントを添える場合
// GetIdAndNamesはDictionary
var idAndNames = GetIdAndNames();

`var`は使うべきか

これはもちろんチームのコーディング規約や方針に従わなければならないが、少なくとも私は個人開発では積極的に利用する。私がアサインされたチームでも今のところ「varは禁止」というところはなかったので非常に助かっている。

MicrosoftのC# のコーディング規則 (C# プログラミングガイド)にも、

変数の型が割り当ての右側から明らかである場合、または厳密な型が重要でない場合は、ローカル変数の暗黙の型指定を使用します。

と明記されている。

【C#】拡張メソッド

2021-01-05T20:44:40+09:00

序論

C#には拡張メソッドという機能があって、まぁ知ってれば大変便利なのですが、弊社謹製レガシーライブラリはなんともまぁ前時代的な書き方をしてあり大変煩わしいしです。そのうえ誰もメンテしないから使いにくくて仕方がない、私がメンテしようにもテストコードすら書かれていないのでめんどくせぇ。というヘイト全開で拡張メソッドの素晴らしさを書いていこうと思います。弊社に届け、この思い☆

拡張メソッド

C#における拡張メソッドは、あたかもそのクラスに元からあるかのように使用できるインスタンスメソッドを実装するという方法です。

たとえば、stringにはstring.IsNullOrEmptyというメソッドがあります。引数で渡された文字列が空白またはnullの場合にtrueを返してくれるというメソッドです。

string text = "";

Console.Write(string.IsNullOrEmpty(text));
// 結果 -> true

この書き方、なんか嫌じゃないですか？つまり、textというインスタンスがIsNullOrEmptyかどうかをいちいちstringのメソッド越しに聞くの嫌じゃないですか？子どもと話してて、お父さんお母さんに「何歳ですか？」って聞いてるみたいで嫌じゃないですか？子どもに聞いて子どもに答えてほしい。なのでそうしましょう。

public static class StringExtension
{
    public static bool IsNullOrEmpty(this string text)
    {
        return string.IsNullOrEmpty(text);
    }
}

上記のメソッドを用意することで、以下のように書けます。

string text = "";

Console.Write(text.IsNullOrEmpty());
// 結果 -> true

比べてみましょう。

string text = "";

Console.Write(string.IsNullOrEmpty(text));  // 拡張メソッドじゃないver
Console.Write(text.IsNullOrEmpty());        // 拡張メソッドver

あらまぁ見てくださいよこのコード量の違いを。素晴らしいですね。

あたかも、textというインスタンスのIsNullOrEmptyメソッドを呼び出しているようでしょう。

拡張メソッド記述のポイント

拡張メソッドのポイントは3つ。

staticクラス内に記載すること
staticメソッドにすること
第1引数の頭にthisキーワードをつけること

こうすることで、そのメソッドをインスタンスメソッドのように扱うことができます。

コードがスッキリする

例えば以下のようなコードがあるとしましょう。

string result = string.Join(",", Enumerable.Range(1, 20).Select(n => ((n % 3 == 0) || $"{n}".Contain("3")) ? "アホ" : $"{n}"));

// 結果 -> 1, 2, アホ, 4, 5, アホ, 7, 8, アホ, 10, 11, アホ, アホ, 14, アホ, 16, 17, アホ, 19, 20

上記コードは1から20のうち、3の倍数と3がつく数字の時は"アホ"を、それ以外はその数字を返すコレクションを", "で区切って連結するというものですが、このコードを読む時って

まずstring.Joinがあることで何かが区切って連結される
何が区切られるかを読む

という順番で読むことになると思います。で、何が区切られるのかを読み始めたらめんどくさいコレクション操作をしていて嫌になりますね。

ですが、以下のような拡張メソッドが用意されていたらどうでしょう。

public static class GenericsExtensions
{
    public static string JoinBy(this IEnumerable source, string separater)
    {
        // nullチェックは省略
        return string.Join(separater, source);
    }
}

これを使うと、以下のように書けます。

string result = Enumerable.Range(1, 20).Select(n => ((n % 3 == 0) || $"{n}".Contain("3")) ? "アホ" : $"{n}").JoinBy(",");

// 結果 -> 1, 2, アホ, 4, 5, アホ, 7, 8, アホ, 10, 11, アホ, アホ, 14, アホ, 16, 17, アホ, 19, 20

これならどうでしょう。対象の数字を"アホ"へ変換した後に、", "で区切って連結させると自然に読めますよね。

この自然に読めるということが超重要なんです。ただでさえ頭を使うことが多いので、不要なストレスを省くようにすべきだと思います。(別の話になりますが、LINQは頭の中のロジック通りに書けて、書いてある通りに自然に読めるので本当にすごい)

拡張メソッドを上手く活用できれば、可読性を上げることもできます。

おまけですが、以下のようなアホ判定拡張メソッドを用意するともっとスッキリすることでしょう。

public static class IntExtensions
{
    public static bool IsMultipleOf(this int value, int @base)
    {
        return (value % @base == 0);
    }

    public static bool IsAho(this int value)
    {
        const int AhoTrigger = 3;
        return value.IsMultipleOf(AhoTrigger) || $"{value}".Contains($"{AhoTrigger}");
    }
}

// こう書ける
string result = Enumerable.Range(1, 20).Select(n => n.IsAho() ? "アホ" : $"{n}").JoinBy(", ");

// 結果 -> 1, 2, アホ, 4, 5, アホ, 7, 8, アホ, 10, 11, アホ, アホ, 14, アホ, 16, 17, アホ, 19, 20

終わりに

拡張メソッドは上記の通りとてもメリットが大きく、一度実装してしまえば使う側は何も考えずに使える素晴らしい機能です。再利用性や拡張性も高いです。

とりあえずよく使うstring.IsNullOrEmptyやstring.Formatなどを拡張メソッドにするだけでもかなり便利になります。

これでみんな幸せになります、めでたしめでたし…と言いたいところですが全然めでたくないのが弊社です。私は日々弊社謹製レガシーライブラリと戦っています。ちくせう。

【C#】string-interpolation(文字列補間)の使い方とメリット

2021-01-04T21:06:50+09:00

序論

なんか最近仕事してて、自分が当たり前と思っていることでも、そうじゃない人もいるんだなぁと改めて思った。これは考えてみれば当然のことではあるんだけど。

先日C#のコードを書いていたら、それを見た人から「これ何？」と聞かれた。C#のstring-interpolation(文字列補間)の書式が分からないらしかった。私はstring.Formatよりも文字列補間式を好むのだが、まぁ分からなければ難しいのだろうか？学習コストはそこまで高くないと個人的には思うし、こういうことがあるのでせっかくならまとめてみようと思った。

まぁそんな固く考えなくてもとりあえず書いちゃえって感じなので書きます。ついでにstring.Formatについてもおさらい。

string.Format

string型にはFormatというメソッドがある。これは文字列の中に{0}などのプレースホルダを設定しておくと、引数をそこに入れてくれるというものだ。

const string name = "あぱしょに";
const int age = 27;

string text = "私の名前は{0}です。年齢は{1}歳です。";
string formattedText = string.Format(text, name, age);

// 結果 -> 私の名前はあぱしょにです。年齢は27歳です。

ちなみにパラメータ引数はobject型を取って内部でToStringしているので型は意識しなくても良い。params object[]を取るので型がバラバラでも構わない。

プレースホルダは同じインデックスを指定するとまとめて入れることもできる。

const string favoriteName = "リンゴ";
const string favoritePoint = "甘い";

string text = "私の好物は{0}です。{0}の好きなところは、{1}ところです。";
string formattedText = string.Format(text, favoriteName, favoritePoint);

// 結果 -> 私の好物はリンゴです。リンゴの好きなところは、甘いところです。

第2パラメータ以降で必要な数は、プレースホルダの数ではなくプレースホルダの種類(割り当てたインデックス)の数である。プレースホルダが2種類で合計3個なら、第2パラメータ以降は2つ指定する。

書式設定を指定することも出来る。プレースホルダのインデックスの後に:を挟んで書式設定を指定する。

DateTime Nov042020 = new DateTime(2020, 11, 4);

string text = "今日は{0:yyyy年MM月dd日}です。";
string formattedText = string.Format(text, Nov042020);

// 結果 -> 今日は2020年11月04日です。

拡張メソッド化

string.Formatをいちいち書くのは面倒なので、拡張メソッドを用意している人も多いと思う。

public static class StringExtension
{
    public static string FormatEx(this string text, params object[] parameters) => string.Format(text, parameters);
}

たとえば上記のようなメソッドを用意しておけば、

DateTime Nov042020 = new DateTime(2020, 11, 4);

string text = "今日は{0:yyyy年MM月dd日}です。";
string formattedText = text.FormatEx(Nov042020);

// 結果 -> 今日は2020年11月04日です。

のように使える。こういう拡張メソッドを用意しておくとタイプ量も減るしテストもしやすいし可読性も上がると個人的には思う。

string.Formatのイマイチな点

2点ある。

パラメータがどのプレースホルダに入るのか分かりづらい
コンパイルエラーを検出してくれない

まずは1点目。プレースホルダが少なければ別に問題ないのだが、たとえば

const string LangName = "C#";
const string LangName_ja = "シーシャープ";
const string DevelopersFirstName = "アンダース";
const string DevelopersLastName = "ヘルスバーグ";
const string ProgrammingLang = "プログラミング言語";
const string LangsGroupOfC = "C系言語";
const string SampleLang1 = "C言語";
const string SampleLang2 = "C++";
const string SampleLang3 = "Java";
const string DevelopersOffice = "ボーランド";
const string SampleLang4 = "Delphi";

string text = "{0}({1})は、{2}・{3}が設計した{4}であり、構文はその名前にもある通り{5}({6}、{7}や{8}など)の影響があるが、構文以外の言語機能などについては{3}が以前の所属である{9}で設計した{10}からの影響がある。";

string formattedText = string.Format(text, LangName, LangName_ja, DevelopersFirstName, DevelopersLastName, ProgrammingLang, LangsGroupOfC, SampleLang1, SampleLang2, SampleLang3, DevelopersOffice, SampleLang4);

// 結果 -> C#(シーシャープ)は、アンダース・ヘルスバーグが設計したプログラミング言語であり、構文はその名前にもある通りC系言語(C言語、C++やJavaなど)の影響があるが、構文以外の言語機能などについてはヘルスバーグが以前の所属であるボーランドで設計したDelphiからの影響がある。

上記のような長ったらしい文字列の補間などは目で追う気にもならない。はっきりと言って苦痛である。(例文はC#のwikipediaのページより拝借した)

こういうコードを書く方が問題だといえば当然そうなのだが、しかし現実問題として先人が書いたこういうコードを読むことが何度もあった。

こういうふうにプレースホルダとパラメータが多いと、対応するパラメータを探すのだけで一苦労であるし、上記では{3}が2回登場しているが、その度にパラメータをまた辿りなおすのも面倒である。

整形後のイメージがコメントで書いてあればまだマシだが、そこまで気が利くような人はこんな長ったらしいFormatを書かないのである。

そして2点目、string.Formatはコンパイルエラーを検知できない。

const string favoriteName = "リンゴ";
const string favoritePoint = "甘い";

string text = "{0}の好きなところは、{1}ところです。";
string formattedText = string.Format(text, favoriteName);   // パラメータに favoritePoint を指定するのを忘れている

// 結果 -> 実行時エラー

上記のコードはプレースホルダに対してパラメータが不足しているため、下記の実行時エラーが発生する。

System.FormatException: 'インデックス (0 ベース) は 0 以上で、引数リストのサイズよりも小さくなければなりません。'

しかし、string.Formatの構文としては正しい(第1引数がstring、第二引数がobject)ため、コンパイルエラーとして検知されない。つまり、実行してみるまでエラーになるか分らないのだ。

上記のような簡単なコードであれば原因も分かるが、「1.パラメータがどのプレースホルダに入るのか分かりづらい」の説明に例示したような複雑に入り組んだコードの場合は原因を探すモチベーションすら湧いてこないだろう。

上記の問題は、いずれもstring-interpolation(文字列補間)を利用することで解消できる。

string-interpolation(文字列補間)

この機能はC# 6.0から利用できるようになっている。

利用するには、文字列の最初に$を付けて、プレースホルダは{}で囲んだ中に直接値（あるいは変数・定数など）を書き込む。

const string name = "あぱしょに";
const int age = 27;

string formattedText = $"私の名前は{name}です。年齢は{age}歳です。";

// 結果 -> 私の名前はあぱしょにです。年齢は27歳です。

書式設定を指定する時は、値の後に:を挟み指定することができる。

DateTime Nov042020 = new DateTime(2020, 11, 4);
string formattedText = $"今日は{Nov042020:yyyy年MM月dd日}です。";

// 結果 -> 今日は2020年11月04日です。

という具合だ。

また、プレースホルダが多い場合でも

const string LangName = "C#";
const string LangName_ja = "シーシャープ";
const string DevelopersFirstName = "アンダース";
const string DevelopersLastName = "ヘルスバーグ";
const string ProgrammingLang = "プログラミング言語";
const string LangsGroupOfC = "C系言語";
const string SampleLang1 = "C言語";
const string SampleLang2 = "C++";
const string SampleLang3 = "Java";
const string DevelopersOffice = "ボーランド";
const string SampleLang4 = "Delphi";

string formattedText = $"{LangName}({LangName_ja})は、{DevelopersFirstName}・{DevelopersLastNameが設計した{ProgrammingLang}}であり、構文はその名前にもある通り{LangsGroupOfC}({SampleLang1}、{SampleLang2}や{SampleLang3}など)の影響があるが、構文以外の言語機能などについては{DevelopersLastName}が以前の所属である{DevelopersOffice}で設計した{SampleLang4}からの影響がある。";

// 結果 -> C#(シーシャープ)は、アンダース・ヘルスバーグが設計したプログラミング言語であり、構文はその名前にもある通りC系言語(C言語、C++やJavaなど)の影響があるが、構文以外の言語機能などについてはヘルスバーグが以前の所属であるボーランドで設計したDelphiからの影響がある。

のように位置と値をセットで記述できるので、string.Formatに比べて読みやすいと思う。

プレースホルダに対して値を設定していない場合はコンパイルエラーとして検出してくれるので便利だ。

const string favoriteName = "リンゴ";
const string favoritePoint = "甘い";

string formattedText = $"{favoriteName}の好きなところは、{}ところです。";    // パラメータに favoritePoint を指定するのを忘れている

// 結果 -> コンパイルエラー

CS1733:式が必要です。

余談

文字列補間とはあまり関係ない余談だが、先日新人さんが

DateTime Nov042020 = new DateTime(2020, 11, 4);

string formattedText = Nov042020.ToString("今日はyyyy/M/dです。");

// 結果 -> 今日は2020/11/4です。

というコードを書いてきて頭を抱えたので、これはちょっとしっかり教えた方がいいかなと思ったのだった。まぁやりたいことはわかるんだけどね…。

日本語であればあまり関係ないかもしれないが、たとえば英語の利用者向けに同じメッセージを同じように書いたら

DateTime Nov042020 = new DateTime(2020, 11, 4);

string formattedText = Nov042020.ToString("It is d.M.yyyy today.");

// 結果 -> I午 i0 4.11.2020 午o4a20.

となってしまう。コード量は増えるが書式設定とメッセージは切り分けるべきだという流れでstring.Formatとstring-interpolationを上記の例で教えた。

以上、余談でした。

【C#】DictionaryのValueにクラスをぶちこむ

2020-12-24T22:18:31+09:00

DictionaryのValueにクラスをぶちこみたい！

突然ですか、「DictionaryのValueにクラスをぶちこみたい！」というわけで。。。

作るもの

環境

VisualStudio2020
.NET Core
コンソールアプリ

やりたいこと

ID（数字）をいれると、IDに紐づいたクラスを取得
取得したクラスから名前を表示

~~…クラスとかで分けなくてもいいんじゃね？というのは大いにわかる~~

今回は私の大好きなナガノさんのキャラクター、ちいかわとハチワレちゃんの名前を取得します。

DictionaryのValueにクラスをぶちこむには…？

ソース

            Dictionary NaganoCharacter = new Dictionary()
            {
              {1 , new Chiikawa()},
              {2 , new Hachiware()}
            };

やること

型になるインターフェイスを作る（ここではINagano）
valueにいれたいクラスに継承（ここではChiikawaとHachiware）※newしないとダメだめ

完成したソースがこちら

using System;
using System.Collections.Generic;
namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            //キャラクターのデータ
            Dictionary NaganoCharacter = new Dictionary()
            {
              {1 , new Chiikawa()},
              {2 , new Hachiware()}
            };
            //ユーザーに入力を促す
            Console.WriteLine("住民IDをいれるんだ！！");

            //ユーザーが入力
            int id = int.Parse(Console.ReadLine());

            //入力されたiDからキャラクターのクラスを取得
            INagano character = NaganoCharacter[id];

            //情報を表示
            Console.WriteLine("この子の名前は" + character.Name + "!!!!!!!!!");
        }
    }
    /// 
    /// キャラクターのインターフェイス
    /// 
    public interface INagano
    {
        //おなまえ
        public string Name { get; }

        //住民ID
        public int Id { get; }
    }

    /// 
    /// ちいかわクラス
    /// 
    public class Chiikawa : INagano
    {
        public string Name { get; } = "ちいかわ";
        public int Id { get; } = 1;
    }

    /// 
    /// ハチワレクラス
    /// 
    public class Hachiware : INagano
    {
        public string Name { get; } = "ハチワレ";
        public int Id { get; } = 2;
    }
}

C#で作ったアプリから標準ブラウザで指定URLを開きたい

2020-12-12T17:27:51+09:00

まあ軽くググって以下の答えが出ますよね。

System.Diagnostics.Process.Start("https://play.google.com/store/apps/details?id=com.bushiroad.kemofure");

でも実行すると例外で落ちる。
「ファイル名を指定して実行」に入力した時と同じ、という説明もあったので、
窓キー＋Rで「ファイル名を指定して実行」にURLを直接入力したら、そっちではちゃんと開く。どうして・・・

というわけで、以下のように書きなおしたところ、ちゃんと開きました。

System.Diagnostics.Process.Start("cmd", "/C start https://play.google.com/store/apps/details?id=com.bushiroad.kemofure");

例外が出る原因が全くわからないけど、とりあえずこれで。
一応後者の方もtry-catchは入れとく。

.NET Interactive で C# と PowerShell を股に掛ける

2020-12-09T02:33:59+09:00

この記事は、「C# Advent Calendar 2020」 9日目の記事、かつ「PowerShell Advent Calendar 2020」 9日目の記事だ。

スミマセン。横着した。

この時期になれば .NET Interactive の Preview 4 が出てるだろうしその記事でも書こうかな～などと目論んでいたものの、残念ながら登場しなかった。

このため、 .NET Interactive .NET 5 対応版の導入と、 Variable sharing の内容でお茶を濁そうと思う。

.NET Interactive のなんたるかについては、以前の以下の記事で取り扱っているので、そちらを参照願いたい。
.NET Interactive の C# REPL を Jupyter で | Aqua Ware つぶやきブログ

.NET Interactive を .NET 5 で動かしてみる

いきなり本題とは関係ない話になるが、せっかく .NET 5 がリリースされたところなので、 .NET Interactive を .NET 5 で動かしてみよう。

12/8 現在、NuGet で公式にリリースされている .NET Interactive は、 9月にリリースされた Preview 3 に少し更新が加えられた、 1.0.155302 だ。
これは、 .NET Core 3.1 上に構築されている。

一方で 11/27 頃のビルド (dotnet/interactive@61d2315) あたりでは、既に .NET 5 対応が済まされている。

更に、何故か Visual Studio Code の .NET Interactive Notebooks 拡張では、 .NET 5 に対応した 1.0.160204 がリリースされている。

このため、現時点で .NET Interactive で .NET 5 を扱う主な方法は、以下の通り。

main ブランチの binder コンテナにアクセス
Azure DevOps の CI ビルドの NuGet feed (dotnet-tools) から、 Glogal Tool を DL
- 実行例:
  powershell dotnet tool install -g Microsoft.dotnet-interactive --version 1.0.160204 --add-source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
VS Code Insider を起動し、 .NET Interactive Notebooks 拡張の Preview をインストール

残念ながら、 .NET Interactive インストール済み Jupyter の docker イメージのようなものは公式では用意されておらず、コンテナを使いたかったら自分でビルドするしかない。
(そのせいで、上記 binder の起動は遅い)

vscode 拡張だと、コード補完が ignore case で効くのでとても書きやすい。
以下、 vscode の .NET Interactive Notebooks 拡張のバージョン 1.0.160204 での実行を前提とするが、他の環境でも同様に動作するはずだ。

なお、起動した Notebook やコンソールの .NET CLR のバージョンを知りたければ、 System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription を実行すれば良い。
.NET 5.x.x と表示されれば、 .NET 5 で起動していることが確認できる。

さて、ようやく本題。

.NET Interactive が面白いのは、ひとつの Notebook 内で、 C#, PowerShell, F# の言語間の変数を共有できる点だ。
悪いなあ、 VB.NET。このツールは3人用なんだ。

この変数を共有できる機能を、 variable sharing という。

使い方はとても簡単で、 #!share --from マジックコマンドで、参照する .NET カーネルと変数名を指定するだけだ。

但し、読み込まれている型の空間は共有されない点には注意だ。
例えば、 C# で定義したクラスのインスタンスを PowerShell で読み込もうとしたり、
PowerShell でロードされているモジュールで定義された型のインスタンスを C# で読もうとすると、エラーになってしまう。
詳しくは、 interactive/variable-sharing.md · dotnet/interactive のドキュメントを参照。

但し、 PowerShell でよく使われる PSCustomObject 型については特別対応が入っているらしく、いい感じに Dictionary に変換されて C# でも扱える。
なにそれ。 PowerShell 内部でも欲しい機能なんだけど。

例えば…
例えば……
………

うーん、よい例が思いつかない…

そもそも、 C# でできることはだいたい PowerShell でできるし、その逆もまた然りなんだよな。
加えて PowerShell では、 Add-Type で手軽に C# のコードを埋め込めるし…

強いて挙げるなら、 PowerShell は、付属のコマンドレットや追加モジュールによって、 I/O 操作やリソースの読み込みにが強い一方で、パイプを交えたデータの処理はだいぶ遅いところだろうか。
例えば、 PowerShell でファイルの読み込みなどを行いつつ、大量のデータの処理は C# で行うといったような使い方はアリかもしれない。

#!pwsh
$data1 = Get-ChildItem *.json -Recurse | Get-Content -Raw | ConvertFrom-Json;
$data2 = Get-Clipboard;

#!csharp
#!share --from pwsh data1, data2
data1.Where(kv => kv.Key == "tools")

#!csharp
data2.First()

この程度のデータ処理なら PowerShell で全く問題ないレベルだが、処理するデータの数が増えてくれば C# で実行するメリットが出てくるだろう。

「C#」の記事 - Crieit

【C#】戻り値がvoidなメソッドで、式形式メンバー＋三項演算子を使う

【C#】LINQ のメソッド名が SQL っぽいからラップする

Select => Map

Where => Filter

OrderBy => Sort

【C#】あえて引数名を書くパターン

【C#】え！！C#でif式を？できらぁ！

C#(.Net 6)でgRPCサーバー on Mac

C#のif文の波括弧{}について

C#でゲームを作った話

C# 8.0のswitch式

_が使われている場合は無視される

複数caseとのマッチは不可

Unityで複数の入力方法に対応するタイピングゲームを作ろう

【C#】「単純なusingステートメント」の違和感

【C#】コメントに書くこと、書かないこと

【C#】DRYとOAOO

【C#】命名って大事だね

【C#】ワンライナーで書ける式形式メンバー

【C#】varの使い方、メリットとデメリット

varは使うべきか

【C#】拡張メソッド

【C#】string-interpolation(文字列補間)の使い方とメリット

【C#】DictionaryのValueにクラスをぶちこむ

C#で作ったアプリから標準ブラウザで指定URLを開きたい

.NET Interactive で C# と PowerShell を股に掛ける

`Select` => `Map`

`Where` => `Filter`

`OrderBy` => `Sort`

`_`が使われている場合は無視される

複数`case`とのマッチは不可

`var`は使うべきか