プ：#ifdef #ifは使っちゃダメ　という記事を書いた。今回はその続編で改善方法などをリストアップ。

■「使っちゃダメ」と言っても
　#ifを使わないと「それはムリ」という時は、もちろんあるのでそこは臨機応変でいい。がしかし、「臨機応変でＯＫ」というと、また野放図に使う人が現れるのでやっぱり、基本的には「使っちゃダメ」を念頭においた方が正解。

■「変数名を変えた時」
　例えばクラスの中のメンバー変数のシンボルを変更したとする。

　通常、この後、コンパイルをすれば、m_pekeを使用している場所がコンパイルエラー（m_pekeが未定義なので）によってアラワになり、m_ponへの変更がスムーズに行く。ついでにm_pekeにまつわる、コードに関して再チェックするのが更にＧＯＯＤ。

　でも #if や#ifdefの影響でコンパイルされないところは、m_pekeが使ってあっても、コンパイルエラーが出ない。

  そして別の担当者が、#if#ifdefの条件を変えてコンパイルしたときにエラーになる。別の担当者だと変更の意味合いがわからない。

　「なんで、コンパイルエラーが出るんだよ」「シンボル変えないでね」「じゃ、シンボル変えないよ～」「この変数なんか変なんだけどな～」とだんだん、淀んでくる。

　これじゃダメなので、#ifdef #ifは使わない方がよい。

■「#ifの代わりにif」
   有効になってない側のソースもコンパイルの洗礼を受けさせるために#if の代わりにifを使う手がある。
↓
　これによって、#if表記で隠されてしまう部分をコンパイルに対して明らかにできる。ＩＳ＿ＤＯＵＢＬＥによって、分岐している不利な部分をいくらかカバーできる。

　※この方法は#ifdef には適用できない。この点に限らず、#ifの方が#ifdefよりまだマシ。

■#ifの中を掃きだす。
　以下のようなソース、#ifの中身が複数行あるのは危険度が高い。
　関数として掃きだすと改善され、その後の更なる改善につながる。
（この記事用にデッチアゲたが、こんな感じのソースが実際にも多く・・・）
↓
　上記太字部分、eto_double()の別関数、別ファイルに吐き出せば、ushi_double();にのみ必要だったヘッダー　ushi_double.hのインクルードの必要がなくなる。これは収穫。

　「そんなヘッダー、この環境にはないよ～」「いじるとコンパイルエラーになっちゃう」「だから、いじらない」という淀みをクリアできる。

　今回はこんなところで。