コーディングスタイルの常識をぶち壊せ

ぶち壊せ常識！リアルエンジニア道第1回

2008/09/29 18:05

ポスト

　エンジニアの皆さんは普段さまざまな常識にとらわれていませんか？そのような常識の多くは、思い込みであり、あなたの能力や生産性を妨げる要因となっています。この連載では固定観念を打ち破り、実務をバリバリこなす鉄人エンジニアへの一歩を踏み出すアイデアの数々を紹介します。

ポスト

はじめに

　エンジニアの皆さんは普段さまざまな常識にとらわれていませんか？そのような常識の多くは、思い込みであり、あなたの能力や生産性を妨げる要因となっています。この連載では固定観念を打ち破り、ユーザー視点でハイクオリティなシゴトをこなす「リアルエンジニア」への一歩を踏み出すアイデアの数々を紹介します。

抜け出せ！英文法の呪縛

　ベテランほど、「だって、そういうもの」的な美にこだわるようです。

　例えば、プログラミング言語は英語を基調としています。「英文法を意識した方が美しい。だって、そういうものだろ」というのはその代表例です。

　まず、能書きなしでこの例を見てください。直感的にどちらが美しいか、子供のようなキレイな心で見てください。

例A

TopMargin = 10;
BottomMargin = 10;
LeftMargin = 20;
RightMargin = 20;

例B

MarginTop = 10;
MarginBottom = 10;
MarginLeft = 20;
MarginRight = 20;

　例Aは英文法に従った記述、例BはMarginを最初に持ってきた記述です。

　どうですか？

　英文法を無視した例Bの方が「Margin」がキレイに揃っていて美しくはないですか。ここまでキレイにそろうと、代入部分「= 10;」とかも揃えたくなるものです。

例C

MarginTop    = 10;
MarginBottom = 10;
MarginLeft   = 20;
MarginRight  = 20;

　さらに美しくなりました。ソースの視認性が上がり、メンテナンスもしやすくなるでしょう。

補足

　最近はクラスで設計するので、

Margin->Top = 10;

　と記述することが多いのですが、あえてネーミングという視点で読んでください。

　常識の呪縛につかまっていませんか？「あるべき美しい姿」と思ってるのは本当に美しいですか？

素晴らしきマルチステートメントの世界！

　「マルチステートメント」。この単語を知っている方、覚えている方、どれくらいいらっしゃいますか？ 80年代前半、主にインタプリタ言語においてもてはやされた、あの記述方法です。

マルチステートメントとは

　今では、

a=10;
b=20;
c=a+b;

　と書くところを、

a=10;  b=20;  c=a+b;

　のように書くのがマルチステートメントです。1行に複数の命令を記述する、とても気持ち悪い記述方法です。

　でも昔はちゃんと意味がありました。まだコンピューターが貧弱だった時代、マルチステートメントで記述することで、

ちょっとだけメモリが節約され、
ちょっとだけ処理スピードが上がった、

　のです。

　その後のコンピューター技術の発達により、マルチステートメントはその意味を失いました……。

復活！今風マルチステートメント！

　まずは次のソースを見てください。月ごとに代入文字列を変える処理、比較的分かりやすいソースです。

switch(month){
    case 1:
        tsuki="一月";
        koyomi="睦月";
        break;
 
    case 2:
        tsuki="二月";
        koyomi="如月";
        break;
 
    case 3:
        tsuki="三月";
        koyomi="弥生";
        break;
 
    case 4:
        tsuki="四月";
        koyomi="卯月";
        break;
 
    case 5:
        tsuki="五月";
        koyomi="皐月";
        break;
 
    case 6:
        tsuki="六月";
        koyomi="水無月";
        break;
 
    case 7:
        tsuki="七月";
        koyomi="文月";
        break;
 
    case 8:
        tsuki="八月";
        koyomi="葉月";
        break;
 
    case 9:
        tsuki="九月";
        koyomi="長月";
        break;
 
    case 10:
        tsuki="十月";
        koyomi="神無月";
        break;
 
    case 11:
        tsuki="十一月";
        koyomi="霜月";
        break;
 
    case 12:
        tsuki="十二月";
        koyomi="師走";
        break;

    default:
        tsuki="";
        koyomi="";
        break;
}

　これを今風マルチステートメントで記述してみましょう！

switch(month){
    case  1: tsuki=  "一月";  koyomi=  "睦月";  break;
    case  2: tsuki=  "二月";  koyomi=  "如月";  break;
    case  3: tsuki=  "三月";  koyomi=  "弥生";  break;
    case  4: tsuki=  "四月";  koyomi=  "卯月";  break;
    case  5: tsuki=  "五月";  koyomi=  "皐月";  break;
    case  6: tsuki=  "六月";  koyomi="水無月";  break;
    case  7: tsuki=  "七月";  koyomi=  "文月";  break;
    case  8: tsuki=  "八月";  koyomi=  "葉月";  break;
    case  9: tsuki=  "九月";  koyomi=  "長月";  break;
    case 10: tsuki=  "十月";  koyomi="神無月";  break;
    case 11: tsuki="十一月";  koyomi=  "霜月";  break;
    case 12: tsuki="十二月";  koyomi=  "師走";  break;
    default: tsuki=      "";  koyomi=      "";  break;
}

　こうなりました。実にコンパクトに、そして視認性良くまとまりました。

　筆者がこれを実践したとき、「なんでマルチステートメントなんだ！」と大いに物議を醸したものです。もう遠い過去のものとされた記述法を持ち出したのですから批判されるのも当然と言えば当然です。しかし一度これに慣れた人はやめられなくなります。

　今一度、良く見てください。

　各caseに対応する処理が縦に綺麗に並び、一目で確認できます。ケアレスBUGの混入が防げるため、メンテナンス性が上がり、またソースもコンパクトにまとまるため、いいことづくめです。

　もし「いや！それはおかしい！」と反論したくなったとしたら、それはあなたが凝り固まった常識に囚われているせいかもしれません。

　ぶち壊せ常識！リアルエンジニア道、ここに極まりです。

注

　例のような単純な繰り返しが続く場合に有効です。複雑な処理を無理矢理マルチステートメントにすることは全くもってお勧めいたしません。

この記事は参考になりましたか？