■

効率化模索

「変数名は意味のあるものをつけること」
コーディング規約のネーミングルールは時折遵守がめんどくさいと思う自分があります。
こんなソースな時とか。

　　string employeeName = employeeMaster.getEmployeeName();
　　int workingDay = employeeMaster.getWorkingDays();
　　return createHTML_hogehoge(employeeName, workingDay);

スコープが短いと同じような文字が多くなる為可読性をさげる要因になることがあるから。
意味のあるものは意味のあるものとして、
意味がなくていいものはなくていいものとして、
使い方を分ければより可読性を高める方法があるにもかかわらず従うのがヤなのが一番の理由。


とはいえ、いやいやだけでは世の中は変わらないので、なんか考えてみる。


基本的なデータ型だけでいいからプリフィックスつけようぜ派のおいらとしては、
世の中にあるネーミングルール至上派としばしばぶつかる。
ネーミングルール至上派は
　(,,ﾟДﾟ)＜Prefixは特に内容が変わるオブジェクトには付けづらい
という１点において全否定する。
ついでに
　(,,ﾟДﾟ)＜わかりやすい名前を付けたらソースもわかりやすいんです。
ともいう。


経験が浅い。


その言葉を発した人間のソースがifとforとtry catchでインデントウェーブを描いていなかったことなど無い。
描かなければそれでいいのかというとそんなこともなくて、そんな人は稀なので、多くは劣化ｺﾋﾟｰの源とされることになる。
それ思えば「その人だけ許す」よりは多少は劣化コピーに対抗しておくことを前提とする予防策をとりたい。
おいらはいつも「今この時」を心配しているのではない。
これが劣化コピーされた時の未来を心配しているのだ。*1
とはいうものの、母数が逆転すればこれにこだわる必要はないのだが。


閑話休題。


プリフィックスとネーミングルールよりコードスタイルのがバリエーションがある。
一番初めのと全く同じ出力結果のコードを変化させていってみることにする。


短くしてみた。

　　string name = employeeMaster.getEmployeeName();
　　int days = employeeMaster.getWorkingDays();
　　return createHTML_hogehoge(name, days);

が、こっちのが勘違いが少なくなってよい感じと思うほう。

　　string strName = employeeMaster.getEmployeeName();
　　int intDays = employeeMaster.getWorkingDays();
　　return createHTML_hogehoge(strName, intDays);

ちょいとひねってみる。

　　EmployeeMaster em = employeeMaster;
　　string strName = em.getEmployeeName();
　　int intDays = em.getWorkingDays();
　　return createHTML_hogehoge(strName, intDays);

いっそこう。

　　EmployeeMaster em = employeeMaster;
　　return createHTML_hogehoge(em.getEmployeeName(), em.getWorkingDays());

でも横長ソースはいくないのでこう。

　　EmployeeMaster em = employeeMaster;
　　return createHTML_hogehoge(
　　　　　　　　em.getEmployeeName(),
　　　　　　　　em.getWorkingDays());

こうなったらこれでもいい気がしてきた。

　　return createHTML_hogehoge(
　　　　　　　　employeeMaster.getEmployeeName(),
　　　　　　　　employeeMaster.getWorkingDays());

でもﾃﾞﾊﾞｯｸﾞのことを思い出すとこう。

　　string strResult = createHTML_hogehoge(
　　　　　　　　employeeMaster.getEmployeeName(),
　　　　　　　　employeeMaster.getWorkingDays());
　　return strResult;

ステップ実行するにしろ、何かに吐き出すにしろ分かれているのはやりやすい。


これらはそれぞれちょっとだけ違う記述。
ほんのちょっとだけ目指すところが違う記述。
べたに書くと鬱陶しくても、インデントと記述形態を変えるとなぜかスッキリ感が出てくることがある。
略式で書くと、それはそれで次の欲がでてくるもだし、
オブジェクト名を削減してもそう。
記述に関する作成コスト、保守コストは細かい話であるもので、
楽な記述は作成コストが安く、スッキリ感は保守コスト軽減に役に立つ傾向がある。


ちなみに実務に則した際に作成コストよりも保守コストのほうがかさむのだが、
　(,,ﾟДﾟ)＜使い捨てやからええねん。
とか
　(,,ﾟДﾟ)＜とりあえず今作ることのほうが大事や
とかはよく耳にする現実がある。


バランス次第だな。


ソースの規模が大きくなればなるほど「とりあえず作る」派の作成コストは、作っている最中のﾃﾞﾊﾞｯｸﾞ、メンテナンスにかかる保守コストを上回る傾向がある。
なんども見ることになるからね。
何度も見るところでなんども理解の為の時間を費やすからトータルの作業時間は増えるのだ。
保守コストはそーゆーのを削減するのも目的とした時に、保守といいながらもリアルタイムに恩恵がある効果がでる。
言い換えれば「とりあえず作る」の作成コストが保守コストよりも安くつくのは小規模で再利用を全く考えない場合に集約されることになる。
まーほとんどんなこたーないってこったな。


スッキリ感と簡単に言いながらも効率を追い求める際に考えることは多いと思う。
誰か研究してないかな。
それはそれとして、
世の中絶対不変なナイスなモンってのはないことを改めて思えば、
ルールに完全などあるわけがなく、
自身でもちょいと状況が変われば変えるといったよなことも足して考えると、
状況において最適化する〜ってなことがいいのかなと思えてきた。


っとするとあれだ。
結論となるのは「ベースを持っとく。あとは交渉次第」だな。

*1:100行200行当たり前のソースが万が一作られても即作り変えられるための備えをしておきたい。予防策予防策。当然現在の負担をできるかぎり増加させないあたりで。