はじめに

いわゆるSIerと呼ばれる会社に入社して、主にSESでの開発業務に従事してきました。
入社後の研修でJavaを学んだあと数年ほどJavaの開発業務に携わっていましたが、ある時C#で新規開発する現場に配属されることになりました。
この時C#は全くの未経験で、Javaが楽しいと感じていたことから色々と不安が大きかったのですが、結果的にC#にハマり、気が付けばC#をやっている期間の方が長くなって久しいです。
そこで、振り返ってみてC#を始めて良かったな、嬉しかったなと思う事柄を書いていきたいと思います。

おことわり

システム開発に関わる感想というのは、プログラム言語の違いだけではなく現場の雰囲気や環境に依存するものと理解しています。
この記事ではJavaとC#を比較して書いていますが、Javaを非難する意図は全くありません。
私は長らくJavaの開発現場には関わっていない為「最近はそうでもない」「新しいバージョンのJavaでは出来る」といったこともあるかと思いますが、特に言及しませんのでご容赦ください。
こういった関係から、この記事のタグには"Java"を含めておりません。

1. 言語のバージョンアップへの追従が早い

C#を利用した現場では、新しいバージョンのC#がリリースされると比較的早い段階で導入される傾向がありました。

入社時、Javaは1.6(Java SE 6)がリリース済で、1.7(Java SE 7)の情報が出回り始めていたころだったと記憶しています。
しかし、研修では1.5(J2SE 5.0)を学び、開発現場では関わった順に1.4(J2SE 1.4)→1.3(J2SE 1.3)→1.5(J2SE 5.0)といずれも古いバージョンを利用していました。¹
C#を始めた後にも短期的にJavaの開発現場にいたこともあるのですが、既に1.8(Java SE 8)がリリースされて1.7の公開アップデートが終了するような頃あいでしたが1.7(Java SE 7)を利用していました。
これらはバージョンアップへの対応が行えなかったという状況でもありましたが、大きな理由は使用するフレームワークが新しいJavaのバージョンでは使えないということでした。

JavaにしてもC#にしてもバージョンアップの度に魅力的な機能追加がありますので、情報としては知っていながらも開発に役立てられないのが歯がゆく感じたものでした。

2. フレームワークの選定が不要

"不要"と言い切ったのは言葉のあやですが、C#では.NET Frameworkが多くのAPIを提供しているので、他のフレームワークを選定するまでも無い場面が多かったです。²
例えば、テキストファイルを読み込んで1行ごとに分解したstring配列を作るなんて処理が1行で書けてしまいます。

string[] list = File.ReadAllLines(@"(ファイルパス)");

Javaで開発していた頃は、まず何かしらフレームワークやパッケージを探すか、共通メソッドを作るといったところからスタートしていました。
実際の開発現場では実行コストや諸々の条件により.NET FrameworkのAPIが必ずしも使用できるとは限りませんが、簡単な検証用プログラムを書いたり、開発者向けのツールを作る時には効率がかなり良くなりました。

3. 文字列の比較が`==`で記述できる

実はこれが最も感動的だったのですが、C#は演算子のオーバーロードが出来るので、参照型である文字列(string)を==で比較が行えます。³

const string CONST = "CONST";
var a = "CONST" == CONST; // true
var b = "const" == CONST; // false
var c = null == CONST;    // false

Javaでは文字列比較はequalsメソッドを使用すると必ず教えられると思いますが、文字列比較は登場頻度が高いだけに結構なストレスを感じます。

// コマンドライン引数で CONST を渡して実行
public static void main(String[] args) {
    final String CONST = "CONST";
    boolean a = args[0] == CONST;      // false
    boolean b = args[0].equals(CONST); // true
}

ちなみに、"CONST" == CONSTとした場合はコンパイラの最適化によって、リテラル指定した"CONST"と定数(final)で定義した"CONST"の参照が同じになる為、比較結果はtrueになります。⁴
実際のコードではリテラルと定数を比較することはまず無いと思うので、注意が必要です。

余談ですが、Javaで文字列をequalsメソッドで比較する都合から、以下のようなコードを書くとtargetがnullの場合、実行時にNullPointerExceptionが発生します。

target.equals(CONST);

これを防ぐために以下のように定数を前に書くというルールが決められていることが多かったのですが、理解はしつつも比較対象が左に来ないことがどうしても受け入れられずもやもやしました。⁵

CONST.equals(target);

その他

他にもいろいろと感じたことはありますので、思い出しベースで度々追記していこうかと思います。
見る人によっては思うところがあるかと思いますが、あくまで「私が開発業務に携わる中でこう思った」ということをご理解頂ければ幸いです。
その上でご意見や経験談等ありましたらコメント歓迎いたします。

J2SE 1.4というと、ジェネリクスが導入されておらずリストは毎回キャストが必要で、拡張for文(C#のforeachに相当)が無い時代でした。 ↩
Webアプリケーションや大規模なシステムを開発する際にはC#でも何かしらのフレームワークを利用することが一般的なので、フレームワークが不要だとは思っていません。念のため。 ↩
全ての参照型で==が使えるわけではありませんが。 ↩
このサンプルのために久しぶりにJavaを書いたのですが、「あれ、Javaも==で文字列比較できるようになった？」と混乱してしまいました(笑) ↩
設計書でも「引数が"CONST"と一致する場合～」と書くことはあっても「"CONST"が引数と一致する場合～」と書くことは無く、設計書とコードを見比べる時に「比較処理間違って実装したかな？」と頭によぎるのでした。 ↩