あぱしょにの投稿 - 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"));

こんな感じで書けます。

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

よく使うディレクトリはショートカットコマンドで開こう

2021-10-28T20:25:58+09:00

今回のは簡単に準備できて恩恵の大きい時短テクです。

ITエンジニア以外の方でも、たとえば頻繁にPC内の特定のディレクトリ(≒フォルダ)を開いてその中のファイルを開く、という方は参考にしていただけるかと思います。

たとえば、趣味でイラストを描いているAさんは、イラストのデータをD:\作業\イラスト\制作中というディレクトリに保存しているとします。イラストを描くために毎日このフォルダを開いているとしましょう。

普通に開くなら、まずはタスクバーからエクスプローラーをクリックして、Dドライブをクリックして、作業、イラスト、制作中とマウスをポチポチと潜っていきますよね。あるいは、キーボード操作に慣れていてショートカットを覚えている人であればWindows+E、Alt+D、そしてパスの入力をしていくかもしれません。

でもこれすら面倒なんですよね。もっと良い方法があります。それはバッチファイルに落とし込んで、ショートカットコマンドで開く方法です。これをすれば一瞬で目的のフォルダを開くことができます。PCに詳しくない人でも簡単に設定できると思います。

@echo off
start "" "D:\作業\イラスト\制作中"

上記のようなバッチファイルを作成し、パスを通しておきます。

バッチファイルの作成とパスを通す方法は【Windows】日付8桁(yyyymmdd)を簡単にクリップボードに入れる方法という記事で詳しく解説しているので、そちらを参照してください。

今回は、制作中というディレクトリを開きたいのでsei.batという名前で保存してみます。これでパスを通すと、Windowsを押してseiを入力するとD:\作業\イラスト\制作中のディレクトリを開くことができます。

ファイルの名前はなんでもいいですが、既にあるファイルと被らないように、かつ覚えやすくタイプするのも面倒ではないシンプルな名前が良いと思います。

これを使えば、

たかし君「カモフラージュのために、保存先をD:\勉強\社会\宿題\2021\202110\穴埋め問題\解答\答え合わせ\秘密\危険\閲覧注意\閲覧禁止\見るな！！！\エロにしたけど、開くまでが面倒だなあ・・・」

たかし君「かえって不便だし、これじゃあ意味ないよ・・・」

といった時にも、一発で目的のブツを開くコマンドさえ用意すれば完璧です。どれだけ長くて複雑なパスでも問題なしです。やったねたかし君！もっとがんばれ。超がんばれ。

コマンドファイルにするメリットは他にも、複数のコマンドをまとめて実行できるという点が挙げられます。たとえば、

イラストのデータを保存しているD:\作業\イラスト\制作中を開く
資料用にダウンロードしたファイルを保存しているD:\作業\イラスト\資料を開く
資料を探したいからPinterestとPixivをChromeで、それぞれ別のウィンドウで開いておく

こういう一連の動作をしたい場合でも、そういう命令を書けばコマンド一発で実行できます。

@echo off
start "" "D:\作業\イラスト\制作中"
start "" "D:\作業\イラスト\資料"
start chrome --new-window "https://www.pinterest.jp"
start chrome --new-window "https://pixiv.net"

もし長期的に作業をするファイルがあるなら、それを直接開くように指定しても良いでしょう。とにかく使い方次第でかなり時短ができます。PC起動時に自動で実行するように設定しておけば、完全に自動化できます。

また、半角入力と思ったら全角入力になってた場合などはWindows seiのつもりがWindows せいになったりします。その場合はせいを削除して改めてseiを入力する必要がありますが、その場合備えてsei.batを実行するせい.batというファイルを作っておくと、いちいち再入力する手間が省けてストレスを減らせるのでオススメです。

@echo off
start cmd /c sei.bat

/cオプションは、実行後にコマンドプロンプトを終了するというオプションです。これがないと、せい.bat経由でsei.batを実行した時にコマンドプロンプトが残ったままになってしまうので入れておきます。

たとえば私はdevdir.batで開発環境を展開するようにしていますが、対応するでｖぢｒ.batを作っています。これを用意しておけば、作業を始める時にWindowsを押してd e v dあたりまで入力すればバッチファイルの候補を挙げてくれるのでEnterを押すだけで良くなります。半角モードだろうが全角モードだろうが、問題なく作業の準備ができてとても良いです。

他にも自動で作業中のファイルのバックアップを作ったりと、アレンジ次第で色々なことができます。興味があれば「Windows コマンド」などでググってみてください。

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はそれに続く単一の処理をするのであり、{}で複数の処理を単一の処理っぽくしているのであって、省略とかではなく本来{}がないのが成り立ち的には正しいのである」とか…。 ↩︎

WEB版Twitterの色を元に戻すぞ

2021-08-14T13:55:16+09:00

Twitterの仕様がまた変更されました。個人的には頻繁に仕様を変えて色々とっかえひっかえ試していき、より良いものを追求するという姿勢自体には賛成ですが、今回の仕様変更はちょっと困るなあ、という感じです。

今回の仕様変更は配色の変更です。これはとても困ります。特に白と黒逆やろ！と思います。絶対間違えて誤フォローや誤フォロー解除が発生しまくるでしょう。なので、私の環境ではWEB版だけでも戻します。内容としてはWEB版Twitterのトレンドとかトピックを非表示にすると同じようなことをします。

使うのはStylebotという拡張機能。分かる人向けに書くと、サイトごとに独自のCSSを記述して上書きして見た目を好きなように変更したり、見たくない要素を非表示にしたりできるというものです。

Chromeの拡張機能ですが、対応するブラウザで使えます。私の場合はBraveというブラウザでも問題なく使用できています。Braveに関して興味があればメインブラウザをChromeからBraveに変えた話をご覧ください。

Stylebotで以下のコードを貼り付けてください。色は好みに合わせて自由にカスタマイズできます。詳しくはHTMLカラーコードなどでググってください。

/* フォロー中の背景色 */
div.css-18t94o4.css-1dbjc4n.r-1niwhzg.r-1ccsd61.r-sdzlij.r-1phboty.r-rs99b7.r-15ysp7h.r-4wgw6l.r-1ny4l3l.r-ymttw5.r-o7ynqc.r-6416eg.r-lrvibr {
    background-color: #09f;
}

/* 保存の背景色 */
div.css-18t94o4.css-1dbjc4n.r-14lw9ot.r-42olwf.r-sdzlij.r-1phboty.r-rs99b7.r-16y2uox.r-6gpygo.r-1b7u577.r-peo1c.r-1ps3wis.r-1ny4l3l.r-1udh08x.r-1guathk.r-1udbk01.r-o7ynqc.r-6416eg.r-lrvibr.r-3s2u2q.r-1glkqn6 {
    background-color: #09f;
}

/* 保存の文字色 */
div.css-18t94o4.css-1dbjc4n.r-14lw9ot.r-42olwf.r-sdzlij.r-1phboty.r-rs99b7.r-16y2uox.r-6gpygo.r-1b7u577.r-peo1c.r-1ps3wis.r-1ny4l3l.r-1udh08x.r-1guathk.r-1udbk01.r-o7ynqc.r-6416eg.r-lrvibr.r-3s2u2q.r-1glkqn6 div {
    color: white
}

/* 未フォローの背景色 */
div.css-18t94o4.css-1dbjc4n.r-14lw9ot.r-42olwf.r-sdzlij.r-1phboty.r-rs99b7.r-15ysp7h.r-4wgw6l.r-1ny4l3l.r-ymttw5.r-o7ynqc.r-6416eg.r-lrvibr {
    background-color: transparent;
    border: solid 2px white;
}

 /* 未フォローの文字色 */
div.css-18t94o4.css-1dbjc4n.r-14lw9ot.r-42olwf.r-sdzlij.r-1phboty.r-rs99b7.r-15ysp7h.r-4wgw6l.r-1ny4l3l.r-ymttw5.r-o7ynqc.r-6416eg.r-lrvibr div{
    color: white;
}

今回行ったのは、開発者モードで該当の要素を見つけ出してStylebotで設定の付与です。Stylebotでも要素選択は可能なのですが、開発者モードで行った方が小回りがきいてやりやすいです。

本来は共通クラスのみ抜き出して少ない記述でやりたかったのですが、あまりにも面倒くさくてベタ書きしました。

上記コードはTwiterの仕様変更で無効になる可能性がありますが、その時はまた同じことをすればいいです。

それでは素敵なTwitterライフを！

メインブラウザをChromeからBraveに変えた話

2021-06-02T20:16:27+09:00

メインで使用しているブラウザを、Google ChromeからBraveに変えました。Braveは高品質な割にはそこまで普及していない気がします。せっかくなので紹介してみようと思います。

Braveについて

BraveはjavaScriptの開発者であるBrendan Eich氏らが開発したブラウザで、無料で利用できます。次のような特徴があります。

Windows/macOS/Linux/Android/iOSで利用可能
標準で広告を非表示にする
広告非表示にともなって読み込むデータ量が減り高速化する
Braveが提供する広告を見ることでリワードを得るプログラムがある

macOSはIntel/M1両対応しているそうです。あとは、他のブラウザもだいたいそうだと思いますが、Chromeの拡張機能がほとんど使えるのと、他のブラウザから閲覧履歴やブックマーク、認証情報などのインポートができます。

Braveは標準でサードーパーティーCookie(以下TPC)をブロックします。TPCとは閲覧しているウェブサイト以外とやりとりするCookieのことで、たとえばこのブログでも表示しているGoogle AdSenseなどがあります。他にはYouTubeの動画に挿入される広告もTPCなので、Braveを利用すればYouTube Premiumのメンバーでなくても広告なしでYouTubeの動画を視聴できます。

なぜBraveを使おうと思ったか

実は私がBraveを利用するきっかけになったのも、この広告が標準で非表示になるという機能です。私はYouTube Premiumに加入しており、特典としてYouTube Musicも利用できますが、YouTube Musicがいつまで経っても使いにくいというかGooglePlay Musicの下位互換のような感じがしていました。一方Apple Musicは以前利用していた時はPC版のアプリケーション以外に特に不満はなく、Apple OneというApple MusicとiCloud 50GBとその他特典がセットになってで月額1100円のサービスを利用しようと思っていました。実は、iCloud 50GB自体は契約していて、それが月130円かかっています。

YouTube Premiumは月額1180円、それに加えてiCloud 50GBが月額130円で、合計毎月1310円支払っていることになりますが、Apple Oneにして、YouTubeの広告をBraveで非表示すれば1100円に抑えることができます。毎月210円浮かせることが出来る訳ですね。210円といってもバカにはできません。仮にあと500年生きるとして、毎月210円圧縮できればトータルで126万円も圧縮できますから。126万円ってすごいですよ。

ただ、いくらBraveによるYouTubeの広告非表示が合法とはいえ、YouTubeが提供していない方法で広告を非表示にして一方的に得するのはちょっと私のポリシーに反するので、Google Oneも利用して、Googleドライブを100GBに設定しようと思います。Googleドライブは無料枠で15GBの容量が提供されている太っ腹なサービスですが、私の用途だと15GBは少なすぎます。常々アップグレードしようと思っていたので、良い機会ですし100GBで契約しようと思います。ちなみにGoogleドライブの100GBプランは月額250円、年間プランだと2500円となり2カ月分お得になります。

導入方法

Windowsの場合はインストーラをダウンロードしてインストールする他、Chocolateyでもパッケージが配布されています。Chocoユーザーはそちらからインストールするのが楽でしょう。

cinst brave -y

macOSではHomebrewで導入できます。

brew install --cask brave-browser

iOS、AndroidはそれぞれApp Store/GooglePlayよりインストールできます。

私の場合はChromeからブックマークと拡張機能をインポートしました。認証関係は1Passwordで管理しているのでインポートしませんでしたが、ブラウザからインポートすることができます。その他、閲覧履歴もインポートすることができます。

あとは好みに応じて新しいタブの設定やテーマ・言語などを設定してください。これも特に説明は不要で、直感的に操作できると思います。

拡張機能

使用している拡張機能は少ない方なので参考になるかはわかりませんが、Chromeで使用していた以下の拡張機能は使えました。

Px Downloader
uBlacklist
Stylebot

注意点として、拡張機能自体のインポートはできますが、それぞれの設定はできません。たとえばuBlacklistであればブロックするルールなどは再度設定する必要があります。まぁ昔のブラウザからコピペするだけでいいのですが。

余談ですがuBlacklistはブラックリスト系の拡張機能としてはとても使いやすいのでオススメです。ドメイン単位や、細かい正規表現を設定して検索結果から排除することができます。私は主にいかがでしたかブログなど低品質なサイトをブロックしています。

その他

初めにさらっと紹介しましたがBraveには、Braveが提供する広告を見ることによってBATというポイント(仮想通貨)を得て、それを特定のサイトにチップとして送ったり、自分自身がリワードとして受け取ることができます。

この機能を有効にすると、一部のサイトではチップを送るという表示がでるようになります。たとえば、Twitterなどにも表示されます。

この一番右のアイコンが、Twitterとは関係ないBrave独自の「チップを送る」ボタンです。普段は煩わしいので非表示にする方法を紹介します。

まず拡張機能のStylebotを開きます。インストールしていない人はインストールしてください。

左上の矢印をクリックし、Twitter上のチップのアイコンを選択します。

Stylebotで「隠す」をクリックすると、非表示にすることができます。

面倒な人は、Stylebotに以下のコードをコピペしてください。

div.ProfileTweet-action.js-tooltip.action-brave-tip {
  display: none;
}

ただし、これらの設定は今後Braveの仕様変更により適用されなくなる可能性があります。万が一再びチップのアイコンが出てきた場合は、同様の手順で非表示にすることができます。

まとめ

実はBraveの存在は結構前から知っていたのですが、肉体的にも精神的にも余裕がなく導入を先延ばしにしていました。もっと早く使ってみても良かったと思います。一時期周囲の猛プッシュでVivaldiを使っていたのですが、Vivaldiは個人的にはあまり使い勝手が良くなかったです。なんかおせっかいな機能もあったりして。たとえばプライベートモードでTwitterにアクセスしたら、保存してあるアカウント情報でログインしますか？と聞いてきたり…。ログイン状態で見たくないからPrivateにしとるんやろがい、という…。

Vivaldiも私に合わないというだけで素晴らしいブラウザなのだろうとは思いますが、Braveは私の用途を完璧にカバーしてくれており、今のところ「なんでこうなってんの？」的なのがないです。めっちゃいいですね。まぁ使用し始めて日が浅いからというのもあるかもですが…。

私のブログ(boyi.sh)にもGoogle AdSenseを利用しており、Braveを使うと標準の設定ではブログ上の広告が排除されるのでまぁあまり紹介したくはないのですが、このブログに関しては別に広告目当てでガッポリ稼ぐぜ！といったブログではないので別にいいです。

将来的にはboyi.shもBraveのクリエーターとして認証してもらい、チップを受け取れるようななればな～とのんびりとのんきに考えているので、その際にはチップを送っていただけるとありがたいです！

【プログラミング全般】「登録する」の意でregistと書くことの是非について

2021-05-12T21:20:27+09:00

はじめに

「登録する」という意味でregistと書くのがあるあるなのかは分かりませんが、色んなプロジェクトで色んな人が書いたコードを見ても、結構registが使われていました。

英語的には誤りであり、registという単語は存在しません。正しくはregisterです。ではなぜregisterではなくregistが使われているのか、そう書いた人ひとりひとりを捕まえて「あなたはなぜregiterではなくregistと書いたのですか？」とインタビューすることはできないので、勝手に推測しています。

registerではなくregistを使う理由を推測

-erが動詞っぽくないから

個人的には一番それっぽい理由だと思います。

registerはまぎれもなく動詞なのですが、-erという接尾辞が「～する人」ということを表すので、-erを抜いたregistが「登録する」ということなのだろう、と思ったのではないかということですね。まぁ分からなくはないですが、辞書引こうよ…とは思いますね。

慣習になっているから

自分たちが手をつける以前のソースコードでびっしりとregistが使われており、registerを使いたいけど統一感なくなるのも気持ち悪いので、いやいやregistを使っているパターンですね。

短い方がいいから

registerという語であることは知っているけど、registの方が短いしチーム内で意味も伝わるからregistにしているパターン。これもなくはないでしょうし、ベテランエンジニアがこんな感じで書いてたら他のメンバーも合わせざるを得ないみたいな感じになりそうです。

insert→ins、update→updみたいに省略してもある程度意味が伝わるので、わざわざregisterと書く必要はないじゃんという発想かもしれません。

おそらく上記のような理由があるのではないかと思います。

ググってみる

「登録する regist プログラマ」みたいなキーワードでググってみたところ、以下の記事がヒットしました。

「登録する」の罠: registは間違い、アクセントにも注意

registerではなんとなく動詞らしく見えないので、こういう勘違いが発生してしまうのでしょう。

「動詞っぽくないから説」を提唱されています。私もそう思います。ちょっとややこしい単語ではありますよね。

この記事へ反応する形で、次のような記事もありました。

正確さよりも意図が“素早く正確に伝わる”ことが重要 - 2011年09月05日

プログラマやＳＥにとって、この単語が正しい英語かなんてどうでもいいことだ。さらに発音なんてさらにどうでもいいことだ。重要なことは、この単語を見た人間（おそらく同じプログラマかＳＥか）が、この単語が付いた機能なりファイルなりの概要を名前から安易にかつ正確に想像できるか？という点にある。

これに関しては半分同意といいう感じです。発音に関しては個人的にはどうでもいいと思います。それは私の周りにもネイティブの英語話者がいないからかもしれないですが、コードレビューしていて「このトライアップロードメソッドは何をしているの？」みたいにカタカナ英語で言いますし双方通じています。

ネーミングから容易に処理が分かるかというのも大事な視点です。

たとえば、認証という単語はrecognitionやcertificationを使うのが妥当だと思われる。しかしrecognitionやcertificationという単語はあまり馴染みが無い。意味を調べるのに辞書を要する人間も多いだろう。さらに文字数も多すぎる。それを考慮して、俺は認証をする機能にはauthという略語（造語？）を良く使う。

これに関しても同意できます。一方、英語の細かいニュアンスの違いを命名に落とし込んであると、より良いコードだなと思うこともあります。たとえば

beginとstartの違い
deleteとremoveの違い
sinceとfromの違い

などがコードリーディングを助けることもあるでしょう。

例として挙げられているものでも、たとえばrecognitionだと「一度認識しているものを改めて認識する」ようなニュアンスの認証ですし(接頭辞re-が付いていますね)、certificationだと「何かを申請して、それが他の誰かに承認される」ようなニュアンスの認証、auth(authentication)だとIDとパスワードを使って認証(本人確認)するようなニュアンスの認証です¹。これらのニュアンスの違いがあるのに、認証は全部authでいいや！というのはちょっとどうかと個人的には思います。

英語はやっぱり大事

そういう意味では、「正しい英語」というのはニュアンスの違いなどの理解が及ぶ範囲であれば、それは重要だと個人的には思います。ただ、registとregisterに関してはニュアンスの違いとかではなくそもそも存在しない語と存在する語の違いなので、ここでは若干違う話題ではありますが。

また、プログラミングはだいたい英語を使うため、正しい英語の重要性みたいなのを理解していないとトンチンカンなコードを書いたりします。一度directoryPassみたいな変数を見たことがあります(おそらく書きたかったのはdirectoryPath)。pathは結構頻出基礎的な単語だと思うのですが、自分より何年も長くコードを書いているような人が間違えていると、ある程度正しい英語を使うクセ付けというか、そういうのは大事だよなぁとも思います。少なくとも分からなかったらググる、あまりにも長くなりそうだったらローマ字で書くとかが「正確に伝わる」という意味ではアリだと思います。ローマ字の是非はまた議論が別れそうですが、個人的にはpathをpassと書かれるくらいならpasuと書いてもらった方が…いやpathくらい覚えてほしいな、やっぱ。

個人的にはregistだろうがregisterだろうが意味は伝わるので、既にregistが使われているプロジェクトではregistを使います。でも自分が0から作るならregisterを使います。IDEの補完機能などを使えば2文字増えようが関係ないですし、逆に2文字をケチって「あれｗこの人registっていう英単語はないって知らないのかな？ぷっぷくぷーｗ」と思われるくらいならしっかり書きます²。まぁ思われても別にいいですけど。

結局は環境次第ということだと思います。メリットデメリットあるので、ある程度クローズドな環境であればregistでもいいんじゃない？とは思いますね。ただ、世界中に公開するようなコードを書くのであればregisterを使っていた方が無難だとは思います。少し紹介しましたが、insert→ins、update→updで伝わるのになんでregistはダメなんだ！と思われたら、中途半端に略してて気持ち悪いからだと思います。中途半端にerだけ省略しても誰も幸せにならないのでregくらいまで省略すれないいんじゃないですかね？regだったら省略しているということが明かなので。registだと若干ひっかかるというか、気持ち悪い感は否めないです。個人的に。

私の理解が正しいかはわからないので鵜呑みにしないでくださいね。 ↩︎
私がregist派のみなさんをそのように思っているという訳ではないですよ。 ↩︎

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);

WEB版Twitterのトレンドとかトピックを非表示にする

2021-04-18T21:20:18+09:00

TwitterのWEB版では、右側に「いまどうしてる？」(トレンド)や「おすすめユーザー」「おすすめトピック」などが表示されています。

トレンドはともかく、トピックに関しては全然使っていないのでハッキリいって邪魔なんですよね。そもそも機能として不要と思うのですが、それに加えてフォローしていないトピックも突然TLに出てきて本当に邪魔です。不必要な情報が視界に入るとイライラするので消してしまいます。

今回はGoogle Chromeで拡張機能を使用しますが、Microsoft EdgeやFirefoxなどもChromeの拡張機能を使用できるので、同じ方法で対応できます。

使用する拡張機能は「Stylebot」という拡張機能です。

手順は次の通りです。

拡張機能「Stylebot」をインストール
非表示にしたい部分を選択して非表示設定

簡単ですね。

まずは、こちらからアクセスし、「Chromeに追加」をクリックして有効化してください。

次に、Twitterを開いて、拡張機能より「Stylebot」を開きます。

すると、次のような画面が開きます。

非表示にしたい項目を選択して、「レイアウト」の「隠す」を選択します。

選択した「いまどうしてる？」が非表示になりました。

同様に他の項目を選択すると、スッキリしました。

この「Stylebot」は他にも文字の色などもカスタマイズすることができます。自分好みのTwitter環境にして、素敵なツイ廃ライフをどうぞ！

ちなみに、手っ取り早く「いまどうしてる？」「おすすめユーザー」「おすすめトピック」を非表示にする場合、「Stylebot」の下の<> コードのところに以下をコピペしてください。

なお、Twitterの仕様などにより無効になったりレイアウトが崩れたりする可能性があります。

.css-1dbjc4n.r-1ysxnx4.r-k0dy70.r-1867qdf.r-1phboty.r-rs99b7.r-1ifxtd0.r-1udh08x {
  display: none;
}

新卒IT社員に伝えたいこと

2021-04-15T20:19:11+09:00

はじめに

プログラムを書いてエラーが出ると「自分が否定された」「尊厳を奪われた」と感じる人もいる、という話

上記のまとめを読んで、何年か前にこういう新人さんがいたことを思い出しました。

せっかくなので私も、IT新人さんへ向けてのTIPS的なものを書いてみようと思います。各所で言われていることかもしれないですが書いてみます。

なお、あくまで私の個人的な考えなのであらゆる組織で通用する考えという訳ではないので注意してください。私自身はそんなに有名なサービスに関わっている訳でもない、ただの地方のエンジニアです。そんなに変なことは書いてないと思いますが、以下を鵜呑みにせず色々な人の「IT新人へのアドバイス」みたいな言葉を見て、必要な情報を取捨選択してください。また、分からない用語などが出てきたら都度ググってみてください。

エラーは怖くない

上記のまとめでも言われていることですが、エラーを怖がる必要はありません。正確に言えば、本番で出たエラーは怖いんですが、開発中やテスト中はむしろどんどんエラーを出すべきだと個人的には思います。

開発中やテスト中にエラーが発生すると、当然デバッグすることになります。すると本番ではそのエラーは発生しません。エラーは本番で発生すると、その調査や修正によりコストがかかります。

それらは実際にリリースされて既に価値を生み出している製品なので、稼働を止めることによる機会損失や、ユーザーの信用を失うことに繋がるからです。

一方、開発やテスト中にバグを見つけて修正することができれば、機会損失や信用の失墜を避けることができます。

上記まとめにもありましたが、エラーや警告のメッセージはあなたを攻撃したりあなたを否定したりするものではありません。逆です。「こういうミスがあるよ」「ここの書き方がちょっとおかしいよ」「一応動くけどデータによってはエラーになるかもよ」と教えてくれるものです。

動いているものが急に止まって、よくわからない英語がダラダラーっと出てくるので怖いかもしれませんが、一つ一つの文章はとても簡単な内容なので噛み砕いて理解するのは簡単だと思います。

使える機能やライブラリは積極的に使う

あなたが何かの機能を作ることになった時、その「何か」は既に他の人が似たようなものを作ったりしていることがあります。

それを自分でやることは、それはそれで良い経験になったりはしますが、ITエンジニアは「面倒なことや難しいことを1と0で解決させる」ことです。要は、基本的に面倒くさがりな人が向いている気がします。誰かが既に作っているものを自分で新しく作るのこと(車輪の再発明と言ったりします)は基本的にはやめた方が良いでしょう。

特にOSSなどで広く公開されているライブラリなどは積極的に導入を検討するのも良いでしょう。それらはあなたが個人で開発するよりも、より大勢の人の目によって使われて何度もバグが修正されていたり、最適化されていたりします。

ただ一点勘違いしてほしくないのは、「自分で書かないだけで、書こうと思えば書ける」という状態にはなっておいた方が良い、ということです。

たとえば配列のソートなんかは、だいたいどの言語でもarray.sort的なメソッドがあります。ソートをするならそれを使えば良く、わざわざソート用のメソッドをあなたが0から実装する必要はありません。

ただし、「じゃあソートってどういうアルゴリズムなの？sortっていうメソッドの中では何をやってるの？」という状態は好ましくないと個人的には思います。そういう状態であれば、ソートをするメソッドを書いてみるのも良いでしょう。それにより配列の特性を学んだり、なぜこの処理だと時間がかかるのか、なぜこの書き方が推奨されるのか、などを実体験として獲得できます。これは大きなアドバンテージで、この体験を積み上げていくことがとても大切です。後に同じような問題が発生した時も、これらの経験から「ここが怪しいんじゃない？」となんとなく分かるようになります。

また、エディターによっては変数名やメソッド名の自動補完や、より良い方法を示したりする機能もありあます(EclipseのContent AssistやVisualStudioのIntelliSenseなど)。それらは便利な反面、「関数名などを中途半端にしか覚えなくなったりタイピングが上達しなくなったりするなどの理由から、新人さんには使わないように言っている」という人に一度だけ会ったことがありますが、個人的には使えるものはなんでも使って言った方が良いと思います。

どうせ関数名は英語が分かればだいたい分かるし、何度も使ううちに覚えていきます。タイピングの上達は確かに大事なことですが、入力補完でtypoを減らせるのも充分なメリットです。毎日何時間もキーボードを叩いていれば自然にタイピングは上達すると思います。それにどうせ後から使う機能ならば最初から慣れておいた方が良いと思います。私だったら、気になったものはなんでも使ってみるように指導します。

ネットから拾ってそのまま使わない

上記と少し矛盾するかもですが、ネットからコードを適当に拾ってきてそのまま使うのは避けた方が良いでしょう。

理由は以下の2つです。

そのまま使うだけでは得るものがないから
ライセンス的に問題があることがあるから

まず1点目ですが、たとえば何かしらの関数をググってコピペして、それであなたがやりたかったことが実現できたとします。すると、あなたのコードを見た先輩や上司が「ここはなんでこの変数名なの？」「なんでこういう書き方をしているの？」などと疑問に思うかもしれません。

そのような質問をされた時に、ネットから拾ってコピペしただけだとスムーズに答えることができません。これだと、先輩の疑問も解消されませんし、何一つ学べていないということになります。ググってコピペするというだけの簡単な作業ですが、せっかくなら何をしているか分かった方が良いですよね？

特にITの世界は移り変わりが激しいので、その記事が書かれた当時ではモダンなコードだったとしても、1～2年経ったら古臭い書き方、懐かしい書き方になっていることもザラにあります。古臭い書き方が常に悪という訳ではないのですが、コードを見る人は「なんでわざわざこんな書き方してるんだろう？」と疑問に思う訳ですね。

また、致命的なバグが含まれている可能性もあります。私が執筆している記事に関してもその可能性はあります。そして、仮にコピペしたコードがバグを引き起こして何かしらの損害を被っても、そのコードを書いてネットに載せた人は一切責任を取ってはくれません。

2点目は、ライセンスの問題です。無償公開してあるものでも、MITライセンスなどは著作権表示が必要です。ライセンスポリシーによっては料金が発生するものもあるでしょう。当然不正使用となると重大な問題、コンプライアンス違反となります。

アウトプットするクセをつける

得た情報は積極的にアウトプットした方が良いです。なぜなら、アウトプットして他の人の視点が入れば、「ここはこんな感じにも書けますよ」とか「他にもこんなに便利なツールがありますよ」など意見交換に繋がるからです。発信した内容(自分が事実だと思っていたこと)に誤りがあればそれを指摘してもらい、正しいことを知るきっかけになったりします。

そしてアウトプットしておくことで、後から自分が見直すことができます。「久々に〇〇をやろうとしてググったら自分が書いたページがヒットした」みたいなのも、たまに見聞きします。

アウトプットするのもいくつか方法はありますが、オススメなのはQiitaです。アカウントを作っていなければ今すぐにでも作って良いと思います。他にも私が利用しているCrieitや¹、ブログを書くというのもあります。QiitaもCrieitも、ブログではWordpressやはてなブログでもそうですが、Markdownで記事を書くことができます。Markdownに慣れておくのも良いと思うので、練習がてら書いてみると良いでしょう。

また、「今から調べることは後からまとめてアウトプットするんや…！」というつもりで情報を集めると、不思議なことに集められる情報の質が上がります。自分の理解を越えて良いアウトプットをすることは出来ないので、良いアウトプットをするなら必然的に自分の理解度を上げることに繋がります。これは最終的に自分が得をします。

また、アウトプットのクセを付ければ、他の人がわかりやすい表現をする練習にもなります。自分だけが分かる書き方ではなく、誰にとっても分かりやすい表現ができるようになります。信じられないかもしれませんが、人によっては「ボタンを押したらデータと日付を画面にオープンする」みたいなことを仕様書に書く人もいます²。結局「どのデータか」「日付はどういうフォーマットか」「画面にオープンするとはどういう意味か」などといちいち質問する必要があり、それは双方にとって不必要なコミュニケーションコストです。初めから分かりやすく書かれているに越したことはありません。

道具にこだわる

あらゆる道具にこだわりましょう。キーボード、マウス、モニター、机、椅子、OS、エディター、その他ツール…挙げればキリがありません。

キーボードなら日本語配列か英語は配列か、フルサイズかテンキーレスか、キーピッチはどうするか、直行配列にするか、セパレートキーボードにするか、トラックポイントは必要か、ワイヤレスか有線か、キースイッチは何方式か、メカニカルなら何軸か。モニターは何枚にするか、アームはつけるか、縦置きか横置きか、インチ数はどうするか、画面解像度はどうするか、デイジーチェーンにするか、など色々と拘こだわることができます。

会社の都合などで、特にハードウェアは望み通りのものを使えないことがあるかもしれませんが、こだわることは大事だと思います。たとえばタイピングしやすいキーボードはそれ自体がモチベーションにもなりますし、見た目でも性能でも気に入れば愛着がわいて長く使いたくなります。職業柄PCに向き合う時間も長くなるので、せっかくなら徹底的にこだわって好きなもので固めた方が楽しいです。

便利なショートカットを覚える

ショートカットはめちゃくちゃ便利です。使いこなせばキーボードからマウスに持ち替える動作が大幅に減り効率化できます。

Windowsであれば

Ctrl + C(コピー)
Ctrl + X(切り取り)
Ctrl + V(貼り付け)
Windows + E(エクスプローラーを開く)
Alt + D(エクスプローラーやブラウザのアドレスバーにフォーカス移動する)
Alt + Tab(表示中のウィンドウを切り替える)
Windows + 数字(タスクバーにピン留めしているアプリを起動)

あたりはマジでよく使うと思います。普段から慣れておくと良いでしょう。付箋などに書いて目に入る場所に貼っておくのも良いと思います。

タイピングに早く慣れる

馬鹿にしている訳ではないですが、「最近の新人さんはスマホ世代なので、タイピングに慣れていないどころかローマ字もよく分からない人が結構いる」みたいな発言を見ました。その状態ではプログラミングはおろか、チャットやメールなども難しいと思うので、とりあえずさっさとタイピングに慣れましょう。

上記にある通りアウトプット記事を書いてみたり、寿司打などのタイピングゲームをすれば慣れてくると思います。ホームポジションを覚えればかなりタイピングもスムーズになるでしょう。たまにタイピングが遅くてホームポジションもめちゃくちゃだけどめっちゃ優秀な人もいますが、まぁしっかりタイピングできるに越したことはないと思うのでしっかり慣れましょう。

プログラミングはほとんどが英語の単語や文章なので、ローマ字のタイピングは得意でも英単語はスムーズにタイピングできないという人もいます。できれば練習の段階で英単語も挑戦するようにしましょう。

タイピングに関してはキーボードとの相性も関わってきますので、自分にあったキーボードを見つけることも重要です。特にホームポジションは変な癖がつくとなかなか矯正できません。私も昔はずっと小さいキーボードを使っていて変な癖がついてしまっています。

わからないことをわからないまま放置しない

これが結構大事かもしれません。わからないことをわからないまま放置すると、後から調べるにも面倒になります。ググれば10秒もかからず調べることができるのですから、せめて概要だけでも知るようにしましょう。SiriやGoogleアシスタント、Alexaなどの音声アシスタントサービスを利用するのも良いでしょう。

ミーティングにPCやタブレットなどを持ち込めるのであれば、ミーティング中に出てきたよく分からん単語をその場で調べたり、メモしておいて後でググったりすると良いでしょう。ミーティングがオンラインであればなおさら簡単にできますね。ちなみに弊社は絶賛オフラインです、本当にありがとうございました。

一般的なことであればググれば分かることが多いですが、詳しい人に聞くのも効果的です。その人独自の視点や体験を交えて教えてくれるかもしれないですし、ググるだけではたどりつけない情報を知ることができるのも、人に質問することの大きなメリットです。人間は知識をひけらかしたい生き物なので、質問されて嫌な人はそんなにいないと思います。先輩だろうが上司だろうがガンガン質問していきましょう。

まとめ

色々と書きたいことはありましたが、まぁ概ねかけたと思います。他にも「ググる力を付ける」「情報取捨選択の力を付ける」「手段にこだわりすぎない」なども書こうと思ったのですが上手くまとめられなさそうなのでやめました。要望があったら書きますので、Twitterなどで反応いただければと思います。

Qiitaに記事はほとんど書いていませんが、アカウントは作っています。Crieitを利用している理由は、メインでブログを書いており、カノニカルURLを設定がQiitaではできずCrieitではできるからです。 ↩︎
組織やチーム内で、最終的なイメージや暗黙の仕様が充分に共有されていればこの粒度でも良いこともありますが…。 ↩︎

【Windows】pixivの署名を簡単に入れよう

2021-03-17T21:06:15+09:00

以前公開した「【Windows】日付8桁(yyyymmdd)を簡単にクリップボードに入れる方法」という記事が意外と読まれていたので、その応用版みたいな話です。

今回はpixivに投稿するイラストなどに入れるサインではなく、説明欄に入れるフッター的な意味の署名の話です。

私も少し前からpixivやFantiaには署名を入れています。

こんな感じですね。

これをやると作品を見てくださった方が他のTwitterやブログなど、他の活動場所にも来ていただきやすくなるかな～…と思って入れています。期間が短く、別に計測している訳ではないので効果の程はわかりませんが。

この署名、入れるのはいいのですが毎回以前のページからコピペするのって結構面倒くさいので、スクリプトで「署名をクリップボードに入れる」ところまでは自動化しています¹。

今回は、署名を書いたテキストファイルを別途用意して、そのファイルの内容をクリップボードに入れるためのスクリプトを用意します。

まず署名ファイルを作成します。

内容は好きに書いてください。署名のほかに簡単なメッセージなどを入れるものありでしょう。

ほげほげ丸
Blog https://example.com
無断転載はお控えください。
Please do not reprint without my permission.

これをtxtで保存しますが、文字コードにANSIを選んでください。他の文字コードだと文字化けしてしまいます。ファイル名はなんでもいいです。ここでは、「signature.txt」という名前で保存したとします。

次に、バッチファイルを作成します。作成の仕方は冒頭で紹介した記事を参照してください。

clip < "signature.txt"

signature.txtの部分は、先ほど作成したファイルに置き換えてください。これもファイル名はなんでもいいですが、「.bat」以外の部分を自分でタイプするので短くて覚えやすい名前の方が良いと思います。また、これも文字コードはANSIを選んでください。「signature」を略して「sig」とかにすると覚えやすいと思います。「shomei」とかでも良いかも。まぁなんでもいいです。

ファイル名にスペースを使っていない場合は、テキストファイル名を"で囲む必要はありません。スペースを入れる場合(「signature pixiv.txt」にする場合など)は、"で囲んでください。空白が入る場合は、"で区切らないと別のコマンドと認識され、正常に動作しません。

あとは作成したテキストファイル(.txt)とバッチファイル(.bat)にPATHを通せば完了です。PATHを通す方法も、冒頭で紹介した記事を参照してください。

これを実行して、テキストファイルに作成した署名がクリップボードに入っていることを確認してください。

私は署名をpixiv用とFantia用に使い分けているので²、テキストファイルとバッチファイルをそれぞれ2つずつ作成し「sip」「sif」というコマンドで運用しています。(それぞれ「signature pixiv」と「signature fantia」略です)

これで、いちいち過去の作品からコピーとかしなくて済みます。いつでもWindowsキーを押してsigpと入力して簡単に署名をコピーできます。やったね！

まぁこんなもの用意しなくてもpixiv側で、各作品に共通の署名を入れられるようにしてくれればそれが一番いいんですけどね。プレミアム限定機能でもいいので…。YouTubeとかは確か、デフォルトのアップロード設定とかで概要のテンプレートを作れた気がします。最悪ああいうのでもいい。

これを応用して、「頻繁に入力したい文字列」があるならコマンド化すると楽かもしれません。メールの署名とかは、各メーリングソフトの機能を使った方が楽だと思います。

よかったらついでに私のpixivとFantiaを見てください(小声)

DOM操作で署名を挿入するようなJavaScriptのコードをブックマークしておき、pixivのページ上で呼び出すという感じで簡単にできると思いますが、やっていいかどうか分からないのでここでは書きませんし推奨もしません。試したい人は自分で調べて自己責任でやってください。 ↩︎
FantiaはURLの内容を勝手に展開してカード状にしてくれるおせっかいな機能があり、それによりデザインが損なわれるので「https://」を省略した文字列を署名に出すようにしています。リンクにはなりませんが見た目崩れるよりは良いので…。 ↩︎

【Windows】日付8桁(yyyymmdd)を簡単にクリップボードに入れる方法

2021-03-05T21:11:41+09:00

PCで作業をしていると、フォルダ名とかファイル名に日付8桁を入れたたいなと思うことがあると思います。例えば2021年3月5日なら「20210305」とかですね。

日付を確認して入れるだけなのですが、いちいちカレンダーを確認するのもめんどいし入力するのもめんどいので楽にできる方法を考えました。

あまり詳しくない方に向けて書いていますので詳しい方からすると長ったらしいと感じられるかもしれませんが、分かる箇所は適宜読み飛ばしてください。

手順

クリップボードに日付8桁(yyyymmdd)を入れてくれるバッチファイルを用意する
PATHを通す
バッチを実行する

の3点です。

バッチファイルを用意

メモ帳を開いて、以下の内容をコピペしてください。

SET /P ="%date:~0,4%%date:~5,2%%date:~8,2%"< nul | clip

ファイルを保存します。この時、ファイルの種類は「すべてのファイル(.)」を選択してください。また、ファイル名は「.bat」まで入力してください

ファイル名は任意の名前をつけてください。ただし、日付をクリップボードにコピーする際にこのファイル名の「.bat」を除いた部分を入力するので、短くて覚えやすいファイル名が良いです。

私は日付(date)8桁ということで「d8.bat」としています。

また、保存先のフォルダはどこでも問題ないので、任意のフォルダに保存してください。デスクトップでもOKです。

ファイルを保存したら、ダブルクリックして実行してください。上手く出来ていれば、一瞬黒い画面が表示されると思います。

また、適当なメモ帳などに貼り付けをして、日付8桁がコピーされていることを確認してください。

簡単に内容を解説しますと、%date%というのは日付を「/」区切りで表示するのですが、今回は「/」部分はいらないので数字の部分だけを抜き出して、クリップボードに格納しています。

PATHを通す

通常、ファイルを実行するにはそのファイルが保存されているフォルダの位置を教えて実行する必要があります。単に「d8.bat」を実行するように命令しても、PCは「d8.batがどこにあるか分からない」ので実行できません。

しかし、PCに「d8.batというファイルはこのフォルダにあるよ」と予め教えてあげることで、「d8.batを実行してね」という命令だけで実行してくれるようになります。

「ファイルがここにあるよ」とPCに教える作業を「PATHを通す」と言ったりします。その作業をここでは行います。

PATHを通すにはPCの設定を行う必要があります。

Windowsキーを押して「path」と入力すると、「環境変数を編集」というメニューが現れるのでクリックします。

「Path」というところをクリックし、「編集(E)...」をクリックします。

「新規(N)」をクリックします。

すると、入力用のテキストボックスが表示されるので、ファイルを保存したフォルダをここに入力します。

たとえば、「D:\tools」というフォルダに保存した場合は、「D:\tools」と入力します。

エクスプローラーのアドレスバーからコピーすることもできます。

入力したら、「OK」をクリックします。

これでPATHを通すことができました。あとは、コマンドプロンプトなどから保存したファイルの名前を実行すれば、クリップボードに日付8桁が保存されます。

実行

コマンドプロンプトやPowerShellから実行するほか、エクスプローラーのアドレスバーなどからでも「d8」で実行できます。特にエクスプローラー上でサクッと実行できるのは、いちいちコマンドプロンプトやPowerShellを立ち上げなくてよいので便利ですね。

また、日付のフォーマットも自由に調整できます。たとえば日時まで入れたい場合は、最初のバッチファイルの内容を変更すれば可能なので、好きにアレンジして使ってみてください！

定期的に貼り付けたい定型文字列なんかも、別のファイル名で登録すると色々はかどるかもしれません。簡単なスクリプトで便利にできるハックは意外と多そうですね！

【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を使うのが一番スマートなのかもしれないが。

デスクトップには何も置かない

2021-01-14T20:07:57+09:00

仕事でもプライベートでも、PCのデスクトップにはファイルやフォルダを置かない派です。ショートカットも置きませんし、ゴミ箱も非表示。一切のモノを置きません。何年か前からそうしています。

なんかデスクトップに色々なファイルが乱雑に置かれていると気が散るんですよね。PC起動した時に色々視界に入るのが嫌というか…。

特にプライベートで使っているPCはお気に入りの壁紙とかを設定していたりするので、それが隠れるのが嫌です。せっかくお気に入りの壁紙にしているのだから隠したくないです。

なんというか、私は自分のことをミニマリストではないと思っているのですが、PCのデスクトップ画面には何も置きたくないし、タスクバーに関しては最低限のものしか置きたくない派¹。というかタスクバーも常時非表示にできるなら常時非表示にしたいと思っています。Windowsでは「自動で隠す」はできるんですけど常時非表示はできない…。「自動で隠す」だとタスクバーがある付近にマウスカーソルを当てるとピョコって出てくるのですが、それが嫌だ。余計に気が散ります。それなら表示されてていいよ、って思うので小さいタスクバーを使っています。

慣れてしまえばデスクトップにファイルとかショートカットとかなくても別に何も困らないんですよね。ソフトの起動もキーボードでできますし。キーボードから手を放してマウスでアイコンをポチってするよりキーボード叩く方が早いですし。PC起動してからマウス一切しようせずサインインする訳ですから、作業始める時にいちいちマウス触りたくないというのもあります。

というかプライベートではファイルはほとんどNASに置いておりローカルのファイルを編集するようなことがほとんどないので、置くファイルがそもそもないんですけどね。

スクリーンショット（またはハードコピー、または画面キャプチャ、他）を一時的にデスクトップに保存することはありますが、それも用が済んだらすぐに削除していますね。（そもそもWindows+Shift+Sを使うことが多いですが）

ちなみに「デスクトップに乱雑にファイルを置いたら重くなるから私は置いていません（キリッ）」という人がたま～にいますが、正直そこまで影響ないだろ…と思っています。デスクトップはCドライブ上にあるので理論上起動時間に影響するかもしれませんが、あったとしても軽微なものでしょう。少なくとも最近のPCを使っていて、デスクトップ上のファイルの有無で起動時間を体感できるようなことはないんじゃないかなぁと思っています。

私がそのように運用しているのは単に気が散るからそうしているだけです。

そもそもデスクトップって「机の上」ですからね。使わん書類とか（ファイル）を机の上に置いているよりは、引き出し（ディレクトリ）に入れて整理した方がなんとなく気持ちいと思います。まぁ人によると思いますが。

ちなみにググってみると仕事ができる人はデスクトップにファイルを置かないというすごく強いタイトルの記事がヒットしましたが、このタイトルはちょっとどうかと個人的には思いますね。デスクトップに色々置いている人で仕事ができる人もたくさんいますし、逆にデスクトップがきっちり整理されていても仕事のできない人もたくさんいるでしょう。要は個人が使いやすいように最適化されているかどうかであって、あんまり因果関係はない気がしますね。

仕事でも必要なファイルやショートカットなどは特定のディレクトリ（たとえばD:\workみたいな）に置いていますし、デスクトップにファイルがなくて困ることは何一つないですね。

フォルダを開くにしてもWindows+Eでエクスプローラーの起動、Alt+Dでアドレスバーにフォーカスできるので、あとは目的のパスを入力するだけです。慣れてしまえばマウスでクリックして潜っていくよりも絶対に速いですし。²

Windowsでスタートメニュー開いて数文字タイプするだけでソフトも起動できます。例えば「vsc」ならVisualStudio Code、
「notepad」ならメモ帳、「calculator」なら電卓、「mspaint」ならペイントみたいに。実際はサジェストが効くので「not」「calc」「msp」あたりまで打ち込んだところで候補に出るのでEnterを叩くだけです。絶対こっちの方が楽だし速い。マウスを持ち替えなくていいし。（Windows+Rでやってもいいですが）

ローカルにファイルが色々あるならEverythingとかを使えばサクッと検索できて楽ですね。（私の場合はNASをマウントしているのであまり使いませんが…）

デスクトップにファイルを置かないような運用のメリットをまとめると

気が散らない
壁紙がしっかり見れるので嬉しい
いちいちマウスに持ち変える動作が減るので時短になる（かも）
ショートカットとか覚えるようになる（かも）

もしやってみようかな！って人がいたらやってみればいいと思います。なかなか快適ですよ。慣れなかったら元のスタイルに戻せばいいしね。

ちなみにこの記事は弊社の某に「デスクトップにファイル置かないとパッと探せないでしょ、置いた方がいいよ～」と言われておこだったので「うるせいやいうるせいやい！」と半ベソで書きました。各々やりやすいようにやれば、別にどんな運用しようがどーでもいーじゃんと思うのですがいかがでしょうか。

多少ならいいですがMacのDockみたいなズラズラズラーってなってるのは苦手です。絶対気が散る。 ↩︎
ちなみにアドレスバーでcmdやpowershellと打つとそのパスをカレントパスにしてコマンドプロンプトやPowerShellが立ち上がります。そういう時もAlt+Dが便利ですな。 ↩︎

【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# プログラミングガイド)

あぱしょにの投稿 - Crieit

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

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

Select => Map

Where => Filter

OrderBy => Sort

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

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

よく使うディレクトリはショートカットコマンドで開こう

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

WEB版Twitterの色を元に戻すぞ

メインブラウザをChromeからBraveに変えた話

【プログラミング全般】「登録する」の意でregistと書くことの是非について

C# 8.0のswitch式

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

複数caseとのマッチは不可

WEB版Twitterのトレンドとかトピックを非表示にする

新卒IT社員に伝えたいこと

【Windows】pixivの署名を簡単に入れよう

【Windows】日付8桁(yyyymmdd)を簡単にクリップボードに入れる方法

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

デスクトップには何も置かない

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

【C#】DRYとOAOO

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

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

`Select` => `Map`

`Where` => `Filter`

`OrderBy` => `Sort`

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

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