ゆるふわで雑な日記

Microsoft系の技術情報を中心にゆるふわに綴っていく予定です

北陸新幹線開通記念！北陸・信州合同勉強会に参加しました。

.NET C#

なんでも北陸（石川と富山）と東京の間の論理距離が近くなったそうで（最短で東京⇔金沢が2:28） と言うものの岐阜からの移動に何か変化があるわけでもないんですが（岐阜⇔金沢は概ね2：40） 今年は北陸皆勤を狙いつつ参加してきました。

続きを読む

Effective C#4.0読書会

.NET C#

と言う会に（時間がある時は）on line（Skype）で参加しています。 ※流石に平日夜に大阪とくれば岐阜県民が生で参加は無理というものでしょう。

それは置いといて…

今回のテーマ（という表現が正しいかは謎ですが）は項目34～36（内容は詳しく解説はしません（できません））でした。 上で詳しく説明はしないと言ったわけですが、いや詳しくは説明しませんが、主な内容としては、34はoverloadは継承クラスで使わない（わかりづらい）ってやつです。 で、35,36はTPL（Task Parallel Library)関連の内容です。 感想としては、@xin9le 先生の有難いお話が聞けて、 とても有意義な時間を過ごせました。知りたい方はこの辺読んでみてください。 内容はもとより、TPLや非同期関連のテーマになった時の会話の脱線具合の大きさと言ったら、参加した中で最大ではないかと思ったわけです。 TPLが正式に採用されて5年位でしょうか、いまだにこれほどの熱を持ったテーマだとは… Effective C#4.0（の時点で）は、非同期構文（async/await）はサポートされていないので、今後も読書会の主題にはならないわけではあるんですが、 今読んでいる僕らには非同期構文の知識と経験があるので、ことあるごとに（特にTPLが主題になっている時）語ることになるんだろうか？ ようやく世間的にはTPLやら非同期構文が普通に使われるようになってきたってこと？ それにしては業務（自分が書いたところ以外）で見たことないんだけどな（正直言うと周りのSkillからして使われたら困ると思うけどw） まあこれらの機能は、実際のcodeの手軽さとは裏腹に結構高度なThread管理をしてくれるので、（debugは多少大変だけど）使う価値は大いにあるものだとは思っています。 というわけで、みんなもっとC#使いましょう。 そこJavaもどきとか言わない（初期の時点のC#がJavaの影響を受けてないとは言いませんし、思ってませんが、今のC#はJavaとは結構違ったものだと思います） そしてそっちはVBでいいとか言わない（むしろVBは簡単にしようとしているのか何なのかわからないけど、色々許容しすぎててかえって複雑化してませんか？） まあ、言語は手段なので、目的を果たして初めて意味があるわけだから、そういう意味ではなんでもいいけど、 Windowsがターゲットの開発だったらC# is Bestは割と自信を持って言えるかな。 話がそれましたけど、こんなことしてますよって紹介になれば幸いかと（Skype枠の参加数にはまだ余裕ありますし、興味がわいた人はぜひ雑談しましょう）。

古典的な入門コードを新しめのC#で書き換えてみる

.NET C# Visual Studio プログラム

プログラム始めた頃に、↓こんなやつ出力した経験はありませんか？
1, 2, 3, 4, 5, 6, 7, 8, 9
2, 4, 6, 8,10,12,14,16,18
3, 6, 9,12,15,18,21,24,27
4, 8,12,16,20,24,28,32,36
5,10,15,20,25,30,35,40,45
6,12,18,24,30,36,42,48,54
7,14,21,28,35,42,49,56,63
8,16,24,32,40,48,56,64,72
9,18,27,36,45,54,63,72,81

続きを読む

ソースコードは人が書いて人が読むもの

プログラム

当たり前なんです。 当たり前なんだけど、それを意識していない人（気づいていないのかもしれない）多くないですか？ まず考えてみてほしい、機械（コンピュータ）が読むのであれば01の羅列が良いはず！ 多少妥協してByteCodeじゃないでしょうか？ 人が（楽に、直感的に）書けるようにしてあるのがProgramingLanguageであり、 それをコンピュータに読みやすくするのがコンパイラ（って認識であってますよね？） にもかかわらず、何故か人に読みにくいコードを率先して書くお方がよくおいでになる… 適切なコメントを記述してあればまだ良いが、そういう方に限ってどうでもいいコメントしか残さない… だからこそ、改めて言いたい！！ ソースコードは書くのも読むのも基本的には人なんです。 確かにコンパイラは構文解析してbinaryCode生成したりはしますが、幸いなことに彼らはそういったことを文句を言うこと（は多少あるけど）黙ってやってくれます。 みなさん、人（人類）に読みやすいコードを書きましょう。 以上、技術の一切書かれていない技術BlogのEntryでした。

コードレビューの最中、素敵なコードを見かけたので

.NET C# プログラム

晒してみる…
以下原文まま（VBです）

Private Function GetPathJoin(meinPath As String, ParamArray joinPath() As String) As String
    For Each joinstring in joinPath
        meinPath += "\" & joinstring
    Next
    return meinPath
End Function

以下機械的にC#にしただけのもの

private string GetPathJoin(sting meinPath, params string[] joinPath)
{
    foreach(var joinstring in joinPath)
        meinPath +="\\" + joinstring;
    return meinPath;
}

このコードは業務で実際に作成されたものです。
見ての通り？業務Logicは含まれていません
これ、どうなんでしょう？
このコードは、private（BL層のclass）に作成されています。
Loopの中で文字列を加算演算子を使って結合しています。
第一引数はstringで、第二引数はstringの可変長引数です

private string GetPathJoin(params string[] joinPath)
{
    return string.Join("\\" , joinPath);
}

このコードと結果は同じでは？
各要素の最後が"\"の場合が想定されていないのが気になります。
全て受け入れたとしても、Path.Combine(params string[])を再作成しているだけだと言うのが特に気になります。
（結果が同じになるとは限らないんですが、目的（文字列要素をPathの構成要素として連結する）がという意味で）
結局、これを書いた方は何を考えていたのかが未だ不明です。
同project内でもPath.Combineは使っているので…
今回はただ愚痴と言うか、文句になっていますが、アンチパターンとして誰かの役に立てばいいなと…