Mr U1's List: sharp coding

• 一般に言われている関数の長さの限界は、プリンタ用紙１枚程度の６０行前後です。まあ、許容 される限界は１００行まででしょう。
• １００行を越えたら、「嫌だなあ」と感じてください。２００行を越えたら、「恥ずかしくて誰 にも見せられない。早く直さねば！」と感じてください。この感覚を身につけることが、初心者卒 業の第一歩です。

• • 戻り値がないルーチン:明確な名詞と明確な動詞を組み合わせる 
  • 戻り値があるルーチン:戻り値が判るように名前を付ける。 
• あまりにも長い名前を付けなければならなくなったら、ルーチンの機能分割が適切かどうかもう一度検討したほうがいいかもしれません。
•                      

  単純なデータによる結合	パラメータによる呼び出し
  データ構造による結合	パラメータに構造体を渡す
  フラグによる結合	パラメータにフラグを渡す
  グローバル変数による結合	パラメータではなくグローバル変数で渡す

   上に行くほど結合が弱く、理想的です。
• • 別のルーチンを呼び出したら必ず戻り値を検査する。 
  • パラメータの値を検査する。 
• パラメータの個数が８個を超えると、バグ件数が急激に増加することがIBMの調査で明らかにされています。
• 明確な理由があるなら、たとえ小さくてもルーチン化するべきなのです。

4 more annotations...

• 
   一般にパラメータの数が８個を超えるとミスをする割合が急激に増えることは本文でも触れましたが、その場合にはこのようにパラメータを構造化するのも一つの回答です。
• typedef struct {  long lEmployeeID;  struct tagEMPDATA {  char szName[40];  char szAddress[100];  long lBirthDay;  char szPhone[20];  } data; } EMPLOYEETYPE;
• ルーチン内で処理対象を切り替えるような作りは、望ましくありません。

1 more annotation...

• 
   モジュールとは、データと、そのデータに関連するルーチンの集まりです。

• sprintf( tn, "%02X", cn );

  • data変換に便利

• マクロ名 ‥‥‥ 全部大文字  変数名 ‥‥‥ 全部小文字  関数名 ‥‥‥ 全部小文字または単語の先頭文字だけ大文字
• 名前のつけ方は、まず、長くしてください。けっして2、3文字にはしないように。まして、1文 字の変数名は絶対やめましょう。

• ハード関係をやっていると、unsigned の方が都合が 良いことが多いのは事実です。でも、なくても良いものは、ない方がプログラムが見やすくなりま す。それではいやだというのなら、 

  	typedef	unsigend char  uchar; 

   という uchar 型を定義して、unsigned char と書く代わりに、たんに uchar と書いた方が見やす いでしょう。
• コンパイルの単位、つまりソースファイルの内部だけに名前を限定し、他の部分から「隠す」と 便利です。外部変数と関数の先頭にstaticをつけるとこの隠す機能が働きます。
• サイズは直接指定せず、初期化データ自体にサイズを決めさせてしまうと、サイズは自動的に適正 な値に決まります。 

    配列宣言のとき、サイズ部分を書かずに [ ] としてしまう方法です。

1 more annotation...

• Ttl, Sum, Avg, Max, Min, Rec, Str, Ptrなど、変数名の前か後ろに付けます。
• first/lastはわかりやすいですが、first/endは一般的ではありません(英語としては)
• add/remove begin/end create/destroy  insert/delete first/last get/release  put/get up/down lock/unlock  min/max next/previous old/new  open/close show/hide source/destination  source/target start/stop

1 more annotation...

• テンポラリ変数は中間結果を格納したり、とりあえず必要な値を保存したりする変数です。tempやXなどを使う傾向にありますが、やめた方がよいでしょう。そのような名前を付けるときは、取り組むべき問題を十分に理解していないことが多いのです。
• • Done ....... 何かが終了したか 
  • Error ....... エラーが発生したか 
  • Found ....... 値が見つかったか 
  • Success ....... 操作が成功したか 
  • Complete ....... 一連の処理が完了したか 
• 変数の型を変数名の最初につけて(プレフィクスするといいます)、プログラマが常にその型を意識してプログラミングする方法
• ハンガリアンネーミング(ハンガリアン記法)という命名法

2 more annotations...

• • クラス名は大文字ではじめる 
  • メソッド(C言語で言う関数)、変数は小文字ではじめる 
  • メソッド(C言語で言う関数)、変数は単語のつながりで表現し、２単語目以降の単語の初めは大文字にする 
• • 変数はデータ型を最初に付する 
  • メンバー変数は「m_」ではじめる 
   

  例） class MyClass{     int     m_nLengthOfLine;     boolean m_bDataFlag } 

•    \b  １文字戻る   \r  その行の先頭に戻る

• 例A

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

  例B

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

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

• 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; } 

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

• list 1 

      if ((fp = fopen(filename, "r")) != NULL) {         ...     } 
• さて、この記法がポピュラーなのは何故か考えてみましたが、おそらくK&Rにごろごろ出てくるからだと思います
• list 2 

      fp = fopen(filename, "r");     if (fp  != NULL) {         ...     } 

• なんだ、あまり変わらないではないか。その通り。でも、あまり変わらないなりにも変わった所を見逃してはなりません。最も顕著な違いは、ifが現われた時の後処理です。先程の例では、まずifを見た時点で、一旦ifの処理中であることを、頭の中のスタックに積まなければなりません。最初の記法では、 

    

   「ふむふむ、if か、もし()の中が真なら{}の処理をするんだな、なになに…」 

    

   と、 

    

   「…結果がNULLでなければ値が真だから、{}の中の...を処理してと…。」 

    

   の間に処理が割り込んでいるため、ifという文字を見てから、条件判断までの間が長くなっているのが一つの特徴です

• list 14

  if (-1 == i) {  ...  }

    

   -1という値にiを代入するというのは、Ｃの文法としては誤りなので、コンパイルの段階で、エラーを発見することができます。従って、間違いはすぐに気付くというわけです。左辺に定数を持ってくると、代入できないということと、比較は左右を入れ替えても結果が同じである、という特徴を活かしており、その意味ではうまい方法だといえるかもしれません。 
• 私の経験では、訳の分からないコメント以上にプログラムを難解にするものはありません。
• なぜ不適切なコメントがいけないかというと、誤った先入観を与えるからです。この先入観というのがくせもので、最もわかりやすい例は、間違ったコメントです。
• 多くの秘伝書に「無駄なコメントは書くな」と記されているのはなぜでしょう。これは裏の意味を考えるとわかります。つまり、重要なのは「必要なコメントを書きなさい」ということなのです。

•   

   ・関数を定義する場合には、それが何をする関数で、どのような場合にどんな値を戻すのかを書く。 

    

   ・変数に対するコメントは、その値がどのような場合に、どういう意味を持っているのかを書く。 

    

   ・繰り返し処理(for, whileなど)に対しては、どのような条件で繰り返すか、または繰り返しを終了するのかを書く。 

    

   ・条件判断(if, switchなど)に対しては、どのような条件の時に処理が実行されるかを書く。
• 当時は、メモリが足りなくなるだとか、こうした方が実行速度が早いだとか、結構空しい理由で、実に見にくいマルチステートメント形式の記述が行なわれたりしたものです
• あまりひどいインデントのプログラムは、階層化された構造を見誤る原因になりますから、すなわちバグの原因にもなるのです
• ソースプログラムを外部に発表する場合には注意してください。この場合は検討の余地があります。他の人もタブが４文字間隔であるとは限らないからです。最悪の場合、タブを認識しない環境もあるかもしれません。
• 実は、MSDOS の type コマンドを使った時など、タブが８文字と見なされることは結構多いので、自然とタブを８文字と考えてコーディングする人か多くなりがちなのですが、それでも、Ｃのプログラムのインデントは、４文字の空白分の間隔としたい、という人が多いようです。

• カンマ（,）、セミコロン（;）の後には、原則として、空白を１つ置く。 

    

          ×  printf("i = %d ",i);                               ^^         ○  printf("i = %d ", i); 

    

   これはＣの書き方というより、英文を書く場合には普通に行われていることです。ただし、英文タイプの場合、セミコロンの後には、２個の空白をタイプするのが普通のようです。 
• 昔、先頭の２文字しか判別に使われない言語があって、a01とa02が同じ変数とされてしまうので難儀したといったような苦労は、もはやあまり経験することもないと思います
• 。C++には、Ｃ言語では予約語とされていないいくつかの語が、新たに予約語として追加されています。

•  struct student {         int grade;         int class;         int number;         char *name;     }; 

    

   この構造体の欠点は、classという名前を使っていることです。将来C++に移植しようとした人が、びっくりするかもしれません。悲惨なことにならないことを祈ります。
• ただ、驚いたことに、わかりやすい名前にしようとさえ、夢にも思わない人が結構いるように思えるのですが。
• argc、argv はそれぞれ関数 main に渡される引数で、コマンドラインのパラメータの数と、各パラメータの文字列へのポインタを順に格納した配列を意味するのが伝統ですから、上のように書いたら目茶苦茶というわけです。

17 more annotations...