名前空間

複数のnamespaceに同じ名前のclassがある場合

①自namespaceにその名前のclassがある場合

自namespaceのclassを使用する場合

名前空間の指定は省略できる(というか普通は省略する)
例 var a = new class1();


他namespaceのclassを使用する場合

クラス名の前に名前空間を指定する
例 var a = new namespace2.class1();
 ※後に出てくるusingによる名前空間の指定による省略はできない

 

②自namespaceにその名前のclassがない場合

usingで使用したい名前空間を事前に指定していない場合

使用したいclassがあるnamespace名を付ける
例 var a = new namespace2.class1();

 

usingで使用したい名前空間を事前に指定している場合

usingで指定した名前空間については記載を省略できる

例 using namespace2;
  (中略)
  var a = new class1();
ただし、他のusingで指定した複数の名前空間に同名classが存在している場合は名前空間の指定は省略できない(ビルドエラーになる)

ビルドエラーになる例

例 using namespace2; //ここにclass1あり

  using namespace3; //ここにもclass1あり
  (中略)
  var a = new class1(); //これはビルドエラー

 

 

 

 

PCのケーブル周りを整理した。

図を書くのめんどくさいのでざっくりメモ。

 

KVMスイッチ(SW-KVM4HDC)についているケーブルがちょっと嫌だった。

なぜか?

①全く使用しないアナログサウンド用のケーブルがついててなにかとほかのケーブルと絡みつく

②DVIケーブルが太くて硬いのでとりまわしがむずかしい

③DVIとUSBが同じ長さで固定されているが最近はDVIのほうにDPとの変換コネクタを挟むことが多いためにUSBのほうが相対的に短くなってしまうのでUSB側の接続時に強めに引っ張る必要が出てきた

 

てなわけで、こいつらまとめて解消すべく添付してたケーブルを全部引っこ抜いて「HDMIケーブル+DVI-D変換」と「USBケーブル」に置換。

 

さっぱりした。

 

 

KVMスイッチの名誉のために付記。

SW-KVM4HDC購入当時は映像出力はDVI-Dが主流でした。

いいタイトルが思い浮かびません。

プログラミングのこと。

 

画面上の部品のプロパティを設定するだけのメソッド(下記)がありまして

private void inittexts() {
this.textBox1.Text = "赤";
this.textBox2.Text = "黄";
this.textBox3.Text = "青";

this.textBox1.BackColor = Color.Red;
this.textBox2.BackColor = Color.Yellow;
this.textBox3.BackColor = Color.Blue;
}

 

画面に部品が一つ増えたがために行追加(下記)する必要がでてきました。

  this.textBox4.Text = "緑";

  this.textBox4.BackColor = Color.Green;

 

さて、これらをメソッドのどこに書くべきか?

①すでにあるコードに準じてTextとBackColorの設定行を分けて記述

②追加した行だけメソッド最下部にまとめて記述

 

まあ普通は①でしょう。

 

で、その後も順調にこの画面に部品が増え続けたとしませう。

private void inittexts() {
this.textBox1.Text = "赤";
this.textBox2.Text = "黄";
this.textBox3.Text = "青";
this.textBox4.Text = "緑";

//(ここに45行)

this.textBox50.Text = "黒";

 

this.textBox1.BackColor = Color.Red;
this.textBox2.BackColor = Color.Yellow;
this.textBox3.BackColor = Color.Blue;
this.textBox4.BackColor = Color.Green;

//(ここに45行)

this.textBox50.BackColor = Color.Black;

}

 

部品を追加する際のコードの物理位置がだんだん遠ざかってきました。TextとBackColorの設定は物理的にセットにしておいてほしかったなぁとこの時点で思うわけです(もっと早く気づけという意見多し)。

お気楽なプロジェクトならさっさと並び替えることでしょう(というかここまでにならない)が、重苦しい現場だとコードを並び替えるだけでも大騒動。それこそ画面全部品設定が正しいか再確認というめんどくさいことに。

 

つらひ。

所得税法がわからぬ。

所得税法がわからぬ。

いまさら職業会計人狙ってるわけじゃない(そこからは完全に落ちこぼれてまつ)のだが、システム屋として何の因果か所得税法の細部を見なくてはいけなくなってしもた。

でーいろいろ調べているうちに不思議な控除に遭遇した。

 

No.1175 勤労学生控除|所得税|国税庁

 

<引用>

勤労学生とは、その年の12月31日の現況で、次の三つの要件の全てに当てはまる人です。

(1)(略)

(2) 合計所得金額が65万円以下で(以下略)

(略)

3 勤労学生控除の金額

(略)
27万円

<引用おわり>

 

控除というのは所得を求めるのに必要なものなのだが、控除を適用する条件に所得があるというのがなんとも理解に苦しむ。

 

たとえば収入80万としてほかの控除がなければ

①勤労学生控除適用する 80万円-27万円=53万円

  所得53万円なので勤労学生控除は適用可で正解

②勤労学生控除適用せず 80万円-00万円=80万円

  所得80万円なので勤労学生控除は適用不可で正解

 

控除を適用したがために当該控除の所得要件をクリアできる場合、どっちが正解なんだろ??

 

 

 

 

 

 

迷路もどきパクってみました。

 むかしむかしのコモドールでの実行画面。シンプルな画面で迷路っぽい出力。

現代のC#でできないわけがなかろうとパクってみました。

 
using System;
namespace ConsoleApplication3 {
    class Program {
        static void Main(string[] args) {
            int c = 0;
            var v = new Random();
            while (true) {
                //(int)'/' = 65295
                //(int)'\' = 65340 = 65295 + 45
                var cc
                    = (char)(65295 +
                    Math.Round(v.NextDouble(), 0, MidpointRounding.ToEven) * 45);
                Console.Write(cc);
                c++;
                if (c == 40) {
                    c = 0;
                    Console.WriteLine("");
                }
            }
        }
    }
}
 
元のコードとはシンプルさにおいて大きな違いがありますが、/と\の文字コードが連続してないやらなんやらで。。。。すんまそ。
んでも実行結果
 f:id:turkey_pc:20170730162937p:plain
 
(追記)配列に逃げたほうがシンプルだったろうなぁ。

現場で見かけたコードのグチ。

 

仕様はざっくりこんな感じ。

テーブル書くのめんどくさいからExcelで書いたスクショ。

f:id:turkey_pc:20170728093852p:plain

 

で、現場にあったコードをざっくり解読すると

-----------------------------------------------------------------

①keycol=2のレコードを全カラム取得

②①をもとにkeycol=2の全カラムを更新(col_99だけは"北海道"に)

 

①SELECT col_1,col_2,col_99,col_100 FROM tbl WHERE keycol = 2;

②UPDATE tbl SET col_1 = "田中", col_2 = "花子" , col_99 = "北海道" , col_100 = "女" WHERE keycol = 2;

-----------------------------------------------------------------

ということであった。

 

なんか裏の意図があったりするのだろうか?(外注さんの仕事なのでいまさら問い合わせもできず)

 

とりあえずtblのカラムを増やす改修の担当が回ってこないことを願っている。

 

 

ListはAdd順らしい

前の続き。

DictionaryはAdd順で列挙してくれるとは限らないらしい(なんせググって見つかったことである)。そしてさらにもうちょいググり続けるとListはAdd順で列挙してくれるらしい???(だんだんあやふやになってきたorz)

 

じゃ、Dictionaryの代わりにListにするかってことで

            var dic = new List<KeyValuePair<int, string>>();
            dic.Add(new KeyValuePair<int, string>(8, "伊丹"));
            dic.Add(new KeyValuePair<int, string>(4, "新伊丹"));
            dic.Add(new KeyValuePair<int, string>(6, "稲野"));
            dic.Add(new KeyValuePair<int, string>(3, "塚口"));

・・・・

new KeyValuePair<int, string>がいっぱいあってうざったい!!!!!!

Dictionaryならすっきりだったのに!!!!

 

てなわけでKeyValuePairのListに特化したClassを作ってみた。

    class ListKeyValuePair<T1,T2> : List<KeyValuePair<T1, T2>> {
        public void Add(T1 key,T2 value) {
            base.Add(new KeyValuePair<T1, T2>(key, value));
        }
    }

うん、やってることは単純だなぁ。これつかうと

            var dic = new ListKeyValuePair<int, string>();
            dic.Add(8, "伊丹");
            dic.Add(4, "新伊丹");
            dic.Add(6, "稲野");
            dic.Add(3, "塚口");

よし、これですっきし。

 

これ実戦投入する気はない(お堅い現場でつので)が、やるだけやったのですっきし。