■
絶望を表す言葉には多々あるが。
例えばこんなソースコードを見たときの気持ちを的確に表せる言葉をボクは知らない。
private void Hogehoge() { // (変数宣言略) try { // (処理略) if( this.Hogege() ) { for( int i = 0; i < array1.length; i++ ) { try { // (処理略) if( i == 1 ) { // (処理略) } else if( i == 3 ) { // (処理略) } else if( i == 4 ) { // (処理略) } } catch{ } // (処理略) if( hageflag ) { // (処理略) } } } // (処理略) for( int j = 0; j < array2.length; j++ ) { // (処理略) if( i == 0 ) { // (処理略) try { // (処理略) } catch{ } // (処理略) } try { // (処理略) } catch{ } // (処理略) } // (処理略) } catch { } }
[効率化模索]ネーミングルールとソースの構造の関係
今までのルールじゃないことを適用してみている。
「プレフィックスもサフィックスも原則禁止でソース作る」
少なくとも今まではStringとintなどJAVAで言うところのプリミティブ型にはつけてた。
全ては保守性向上のため、
ぶっちゃけヘンに勘違いされ、ヘンに凝られてくちゃくちゃな追加変更を入れにくいようにドン臭くも理解を促すための１手を選んでいた。
例えば次のような短いメソッドならプレフィックスは邪魔っぽい。
private bool Hogehoge( int intID, String strName ){ if( intID < 0 ){ return false; } return base.RegistNewMember( intID, strName ); }
プログラミングと名の付く例題に取り上げられるのはえてしてこんな短いソースだ。
こんな程度なら無いほうがむしろすっきりする。
private bool Hogehoge( int id, String name ){ if( id < 0 ){ return false; } return base.RegistNewMember( id, name ); }
が。
がしかしである。
初心者とか自称上級者達がこんな短いメソッドをたくさんつくることをするだろうか。
応えはもちろん否である。
上部の例題みたいなのにせめてプリミティブ型だけにでもプレフィックスがあったらと思えることは多々ある。
っつか、上部の例題みたいなソースを見て
「プリフィックスとか無いほうがみやすいよねー」とか
「スマートだよねー」とか
言えた事は無い。
目の前で言われた日には手元にハンマーがあったらピコッと殴ってると思う。
ここにボクとしては発見があったんですよ。
そう。短ければスマートに見えるんです。
美しく構造化されたソースコードならば確かに「プリフィックスなんていらんのですよ」と言えるんですよ。
例えばこんなソースなら、paramがなんだとかlistがどうだとか細かいことはさて置いても理解に苦しむことはないだろうと思う。
// ///コメント略 private bool QueryHogehoge( QueryParameter param, out QueryResult result, ){ result = null; if( param == null ){ return false; } DBItem db = this.CreateConnect(); try{ // パラメータ内容のチェックと必要なら一部調整 bool res = this.CheckHogehoge( ref param ); if( !res ){ return false; } // いよいよ実行 List<NantaraClass> list; res = db.QueryToList( param, out list ); if( !res ){ return false; } // 後始末 res = this.ListToResult( list, out result ); if( !res ){ return false; } } catch( Exeption ex ){ // (処理略) return false; } finally { if( db != null ){ db.Dispose(); db = null; } } return true; } // ///コメント略 private bool CheckHogehoge( ref QueryParameter param ){ // (略) } // ///コメント略 private bool ListToResult( List<NantaraClass> list, out QueryResult result ){ // (略) }
戻り値の返し方とか、Connectのポイントとかあーしたいこーしたほうがいいとかは
好きにしてくれと言ってもそうそう崩れない形と思いたい。
さて。
こーゆーような事、次に挙げるポイントが実現できているのならネーミングルールなんざ好きにしてくれと言える。
・インデントウエーブに見えるものが無い*1
・メソッドが細切れにされてもわけがわからんことにならないように１つの役割を明確に持っている
・クラス自体の行数はさて置いても1メソッドあたりの平均は1画面によゆーで収まっている
・かつ行を詰めるためにごちゃごちゃした処理にはしていない
プログラムソースコードの8割くらいは代入とマッピングと流れの制御なんだから、
ごく一部にあるコアな処理を除いては特殊*2なことはやらないほうがよいのである。
まとめ。
構造化も出来ないような初心者は、整理が思うように出来ないんだから、整理しやすくなるための努力は惜しむな。
Stringには「str」とかつけとけ。Integerには「int」とかつけとけ。
それ以外と自負するもの達は、
クラスに役割を、メソッドに役目を与えて決めて、長くなったら分割することを自分の決め事としておいたらそうそう崩れはしないもの。
ネーミングとか好きにつけとけ。おそらく必然として適したものになっているはずだから。
「Animal cat」とか「Animal dog」とかそんな構成とかにはまかり間違ってもならんしな。
[雑感]分割と再構築
いつからやり始めたんだろとふとおもた。
とりあえず動くものを作るためにだらだらと処理を連ねていったら理解に苦しんだあの頃。
とりあえず動くものを作ってから、改めて作り直しても時間的にはかわらねんじゃね？と思い立ったあの頃。
動くものをつくり学習の成果とし、学習の成果を持って物事に取り組むことは保守性を高めるためによいと言う言葉を見つけた頃。
何が違うんだろうなとか思う。
作っているものは所詮テキスト。
でもテキストの作り方でこんなにも世の中の大の大人達はあーでもないこーでもないと世代を超えて悩んでいるわけだ。
そうだ。
「たまには世の中のジジイどもの言葉でも試してみるか」と思って読んだ本のなかから得られた「同じような到達点」の手順を試した結果、
「おおすげぇ！！」っと当たり前と思えたことが当たり前に現実になって驚いた。
自力でなんでもするのがステキと思っていた頃が僕にもありましたよ。
ジジイの言葉何ざクドイ以外の何者でもないと思っていましたよ。
役に立つことなんてあったあった。よくみたら結構いっぱいあるある。
自分の役に立ったら初めて態度を変える。我ながら現金なもんだ。
それからだな。
当たり前を当たり前に出来れば当たり前の結果が伴うんだ。化学反応みたいなもんだ。
「少しくらいこんなふーにしても・・・」とか「こんなんでもいけるはずや」とか当たり前から外れたら行動をいれたら、結果は当たり前から確率になる。
だから、ソースコードを作るときには当たり前に動かしてみて、当たり前に分割するようになった。
役割を見直して、見直したら2度と見なくていいように役目とかをコメントに込めて折りたたんで終了するようになった。
最も手順が少なくて済む段階から手を尽くす。
これが当たり前の結果を生むんだな。
スパゲティも100本あったらとれないけれども、２〜３本ずつなら解き安いもの。
そうだ。
巨大なメソッドを作らなくなれた理由みたいなものはたったこれだけだ。
