MW211 EXIT

devlog
定数の値
2011年09月25日
定数の値はたいてい「1,2,3…」とかだ。
┌─┬─┐
│ 1│男│
├─┼─┤
│ 2│女│
└─┴─┘
みたいな感じ。

ふと、数値じゃなくてもいいんじゃね?とか思い、「male、female」の頭文字をとって
┌─┬─┐
│m │男│
├─┼─┤
│f │女│
└─┴─┘
な~んて定義してみる。

同じじゃん。こっちの方が直感的でわかりやすいし。オレって天才。
なんて思っていると実は落とし穴に嵌っていることに後から気づく。

そう、ソート順のキーに指定した場合「女→男」の順なってしまうのだ。

定数の値は、並び順の番号と心得るべし。

#順番については男尊女卑ではありませんのであしからず
分類:SQL、注意、設計
switch-case文の字下げ(インデント)
2011年08月15日
switch-case文は、caseを一段下げると見やすいので、
以下のような感じで字下げを行っていた。
┌───────────┐
│switch (判定項目) {   │
│  case 判定値:        │
│    処理;             │
│    break;            │
│  case 判定値:        │
│    処理;             │
│    break;            │
│  default:            │
│    処理;             │
│    break;            │
│}                     │
└───────────┘
だが、処理中にif文のネストを入れてみると、caseと同じ階層に閉じ括弧「}」がなく
間延びしていることがわかる。
┌───────────┐
│switch (判定項目) {   │
│  case 判定値:        │
│    if (判定文) {     │
│      if (判定文) {   │
│        if (判定文) { │
│          処理;       │
│        }             │
│      }               │
│    }                 │
│  @←この階層に「{」がない
│    break;            │
~~~~~~~~~~~~~
│}                     │
└───────────┘
ということで、以下のようにswitchの階層とcaseの階層を同一としようと思う。
┌───────────┐
│switch (判定項目) {   │
│case 判定値:          │
│  処理;               │
│  break;              │
│case 判定値:          │
│  処理;               │
│  break;              │
│default:              │
│  処理;               │
│  break;              │
│}                     │
└───────────┘
ちょっと違和感があるが、慣れの問題なのだろう。
ちなみにif-else文との対応関係であれば、以下のような感じだ。
であれば、後者(右)に統一したと思えばいい。
┌───────────┐┌───────────┐
│if (判定文) {         ││if (判定文) {         │
│    処理;             ││  処理;               │
│  } else if (判定文) {││} else if (判定文) {  │
│    処理;             ││  処理;               │
│  } else {            ││} else {              │
│    処理;             ││  処理;               │
│}                     ││}                     │
└───────────┘└───────────┘
┌───────────┐┌───────────┐
│switch (判定項目) {   ││switch (判定項目) {   │
│  case 判定値:        ││case 判定値:          │
│    処理;             ││  処理;               │
│    break;            ││  break;              │
│  case 判定値:        ││case 判定値:          │
│    処理;             ││  処理;               │
│    break;            ││  break;              │
│  default:            ││default:              │
│    処理;             ││  処理;               │
│    break;            ││  break;              │
│}                     ││}                     │
└───────────┘└───────────┘

…と思ったが、使ってみるとことのほか見づらい。
if文を使わずswitch-case文を使っているメリットが半減したようだ。
ということで、特例的に字下げは元のままとしようと思う。
これはあくまで与太話ということで。。。
分類:設計
ER図の矢印の向き
2011年08月04日
電流はプラス極からマイナス極へ進むが、
その中を流れる電子はマイナス極からプラス極へ進むらしい。

ER図の矢印は「1対多」関係の場合、「1 → 多」の向きに矢印を記述するものだ。
しかし、外部キーと主キーの関係についてポインタ的矢印で表すと
「外部キー → (参照先テーブルの)主キー」の方がわかりやすい。

例えば、個人が属している組織名を取得する場合
「(個人の外部キーである)組織ID → (組織の主キーである)組織ID (→組織名)」
みたいな流れだとわかりやすい。

しかし、これだと「個人 → 組織」で、「多 → 1」と矢印の向きが逆になる。
「個人」から「組織」(名)は一意に決まるのだから、「個人 → 組織」の矢印の向きだ。

う~ん、ややこしい。
表単位では「→」でも、列単位だと「←」となってしまう感じだ。

この紛らわしさを回避するために、表単位の「1 → 多」の矢印を、
別の記号(「─●」とか「─∈」(カラスの足)とか)にする場合もあるようだ。

ちなみに「外部キー」とそれが指し示す「主キー」の関係って
「大企業の平社員」と「下請け先の中小企業の社長」みたいな関係だなと思った。
分類:設計
矛盾
2011年08月02日
(C言語系プログラムの)コーディング規約で、
「switch-case文にはdefaultおよびbreakを必ず記述すること」ってのと、
「実行されない処理は記述しないこと」ってのが、併存していることがある。
break直前にcontinueを記述することになったら…。

追記:continueを禁止にすればよいか。。。
分類:設計
前へ 1 2 3 4 5 6 7 8 次へ