barrinの日記: コンパイラがだす警告には正しく対処せよ 1
間違ってもキャストでごまかすことなかれ。
これはワーニングではないですが、const int の配列の配列へのポインタを宣言できなくて、intの配列へのポインタにキャストされてるのをみて目が点になったことがあります。
ほかによくあるのが関数の引数にキャストをつかっているもの、プロトタイプ宣言の意味が。。
barrinさんのトモダチの日記、みんなの日記も見てね。 アナウンス:スラドとOSDNは受け入れ先を募集中です。
間違ってもキャストでごまかすことなかれ。
これはワーニングではないですが、const int の配列の配列へのポインタを宣言できなくて、intの配列へのポインタにキャストされてるのをみて目が点になったことがあります。
ほかによくあるのが関数の引数にキャストをつかっているもの、プロトタイプ宣言の意味が。。
シンタックスシュガーとはその言語でよく使う構文だから言語設計者が親切に設定してくれているものなので、これを利用しない手はない。C言語の関数名、配列名の式での扱いを理解してないせいか、
int foo(int *p, int (*f)(int))
{
return (*f)(*(p+100));
}
とかわざわざ読みくい書き方をしているコードを見ることがある。素直に
int foo(int *p, int (*f)(int))
{
return f(p[100]));
}
と書けばいいのにね。他にも(*p).hoge とか、->演算子の立場がない...
良いコメントはプログラムの理解を助けるが、悪いコメントは理解を妨げる。
悪いコメントの典型例はコードを翻訳したコメントだ。情報量としてまったく増えていないし、
バグフィックスやメンテナンスでコードとずれが起きたときには嘘が書いてあるコメントになってしまう。
変更履歴をコメントに残すのは構成管理ツールを使っていないことを宣伝するようなものだ。
処理の塊に名前をつけたいときにはコメントではなく関数にしよう。
foo()
{
/* goo処理 */
....
/* foo処理 */
....
}
ローカルな定数宣言や変数宣言が書いてあるヘッダファイルを時々見かける。
ヘッダファイルを字義通りプログラムの最初の方に書くものを置くファイルと考えてるのだろうか。
余計な情報が漏れると、それに依存した利用をされる可能性があり、
マーフィーの法則にしたがって、利用されてしまう。
一度利用されてしまえば、ローカルであったはずの定数はグローバルになってしまい、
ローカルな都合では変更ができなくなってしまうか、変更したときに予期せぬバグをもたらす。
表に出さなくてよいものは徹底的に隠そう。
といっても初心者には解からないだろうから
翻訳しないといけないのだが、さてどうしたものやら。
たとえば
foo(int x)
{
if (x) {
処理 xx
}
else {
処理 yy
}
}
のような真偽値のみの引数をもつ関数も
foo_xx(void) {
処理 xx
}
foo_yy(void) {
処理 yy
}
に分割してしまったほうがよい。
「変数名は他人にも解るよう、長い名前をつけましょう」と教えられたことを鵜呑みにして
for (loop_counter = 0; loop_counter < 100; loop_counter++) {
sum += array[loop_counter];
}
なんてコードを書くひとがいる。
上の例で「他の人にも解かる」必要があるのは sum や array であって loop_counter ではないのに。
本来の処理が次のようなものなら
for (i = 0; i < 100; i++) {
TotalPrice += ShoppingItems[i].Price;
}
足し上げのためのうたかたの変数にすぎないiは目立たないように短くあるべきなのだ。
関数にすることで、
・条件文が短くなる
・名前をつけることで真偽がわかりやすくなる
・条件をパラメタライズできる
・条件の詳細を一度に変更できる
・似たような条件分岐がまったく同じ条件なのか、+αがあるのか一目でわかる。
最後の項の例だが、数行もの条件式が5回コピペされていて、そのうちのひとつだけが微妙に違うコードをレビューしたことがある。
人間に間違い探しをさせるようなコードは地獄へ送られるべきである。
世の中には
・数千行の巨大関数
・コピペされた数百の一行違いのメソッド
・十数段のインデント
・内部データ構造が丸見えのインターフェース
・単純ループ変数名が、uc_loop_counter、でも配列名はarray
などなど、想像もつかないコードを書くひとがいるものですが、
プログラミングの本ではそのあたりを説明した本が少ないのに気づいたのが、
教科書を書こうと思った理由だったりします。
前々から、プログラミングの教科書を書きたいと考えていた。
巷にあるプログラミングの本と言えば、言語の使い方ばかりで、
プログラミングに共通の知識や、技術が説明された
これからプログラマになりたい人むけの良書がなかなかない。
なので
・分割して統治せよ
・読めるように記述せよ
・(もうひとつ大切なものがあったのだが思い出せない)
について書き溜めていこうとおもう。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア