パスワードを忘れた? アカウント作成
115734 journal

barrinの日記: コンパイラがだす警告には正しく対処せよ 1

日記 by barrin

間違ってもキャストでごまかすことなかれ。
これはワーニングではないですが、const int の配列の配列へのポインタを宣言できなくて、intの配列へのポインタにキャストされてるのをみて目が点になったことがあります。
ほかによくあるのが関数の引数にキャストをつかっているもの、プロトタイプ宣言の意味が。。

113943 journal

barrinの日記: シンタックスシュガーは良く味わおう

日記 by barrin

シンタックスシュガーとはその言語でよく使う構文だから言語設計者が親切に設定してくれているものなので、これを利用しない手はない。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 とか、->演算子の立場がない...

113275 journal

barrinの日記: 書いてはいけないコメント 3

日記 by barrin

良いコメントはプログラムの理解を助けるが、悪いコメントは理解を妨げる。
悪いコメントの典型例はコードを翻訳したコメントだ。情報量としてまったく増えていないし、
バグフィックスやメンテナンスでコードとずれが起きたときには嘘が書いてあるコメントになってしまう。
変更履歴をコメントに残すのは構成管理ツールを使っていないことを宣伝するようなものだ。
処理の塊に名前をつけたいときにはコメントではなく関数にしよう。

foo()
{
  /* goo処理 */
    ....
  /* foo処理 */
    ....
}

110961 journal

barrinの日記: 公開しなくてよい情報は隠そう 3

日記 by barrin

ローカルな定数宣言や変数宣言が書いてあるヘッダファイルを時々見かける。
ヘッダファイルを字義通りプログラムの最初の方に書くものを置くファイルと考えてるのだろうか。
余計な情報が漏れると、それに依存した利用をされる可能性があり、
マーフィーの法則にしたがって、利用されてしまう。
一度利用されてしまえば、ローカルであったはずの定数はグローバルになってしまい、
ローカルな都合では変更ができなくなってしまうか、変更したときに予期せぬバグをもたらす。
表に出さなくてよいものは徹底的に隠そう。

107898 journal

barrinの日記: もっとも疎結合になるように分割する 2

日記 by barrin

といっても初心者には解からないだろうから
翻訳しないといけないのだが、さてどうしたものやら。

107192 journal

barrinの日記: ひとつの関数ではひとつの処理のみ 2

日記 by barrin

たとえば

foo(int x)
{
    if (x) {
      処理 xx
    }
    else {
      処理 yy
    }
}

のような真偽値のみの引数をもつ関数も

foo_xx(void) {
  処理 xx
}
foo_yy(void) {
  処理 yy
}

に分割してしまったほうがよい。

106759 journal

barrinの日記: 短い名前にも理由がある 2

日記 by barrin

「変数名は他人にも解るよう、長い名前をつけましょう」と教えられたことを鵜呑みにして

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は目立たないように短くあるべきなのだ。

106268 journal

barrinの日記: 条件式は関数にしよう 8

日記 by barrin

関数にすることで、
・条件文が短くなる
・名前をつけることで真偽がわかりやすくなる
・条件をパラメタライズできる
・条件の詳細を一度に変更できる
・似たような条件分岐がまったく同じ条件なのか、+αがあるのか一目でわかる。

最後の項の例だが、数行もの条件式が5回コピペされていて、そのうちのひとつだけが微妙に違うコードをレビューしたことがある。
人間に間違い探しをさせるようなコードは地獄へ送られるべきである。

105766 journal

barrinの日記: せめてレビューできるコードを 3

日記 by barrin

世の中には
・数千行の巨大関数
・コピペされた数百の一行違いのメソッド
・十数段のインデント
・内部データ構造が丸見えのインターフェース
・単純ループ変数名が、uc_loop_counter、でも配列名はarray
などなど、想像もつかないコードを書くひとがいるものですが、
プログラミングの本ではそのあたりを説明した本が少ないのに気づいたのが、
教科書を書こうと思った理由だったりします。

105329 journal

barrinの日記: プログラミング教科書 13

日記 by barrin

前々から、プログラミングの教科書を書きたいと考えていた。
巷にあるプログラミングの本と言えば、言語の使い方ばかりで、
プログラミングに共通の知識や、技術が説明された
これからプログラマになりたい人むけの良書がなかなかない。
なので
・分割して統治せよ
・読めるように記述せよ
・(もうひとつ大切なものがあったのだが思い出せない)
について書き溜めていこうとおもう。

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...