■Contents
コーディング規約
if(条件)文の書き方
データ圧縮
演算を高速に
条件マクロの多いソースを読みやすく
makefileの依存関係を自動生成&makefile雛形
ビットを扱う
ソフトウェアの解析術
このページで使用するmakefile
割り算と掛け算
defineとconstの違い
役に立つ書籍


ページ先頭へ

■if(条件)文の書き方
  • 範囲指定の書き方
    多くの方は、変数を左辺、定数を右辺に書く方が多いように感じます。
    ただ、範囲指定の場合、どちらが見やすいでしょうか?
    ・if( val >= 0 && val < 100 ){ ...
    ・if( 0 <= val && val < 100 ){ ...
    多くの方は、下の例のほうが見やすいと感じたはずです。
    あまり固定概念にとらわれることなく見やすいコードを書きたいものです。
  • エラー?仕様?
    時折、エラーなのか仕様なのか分からないコードを書く人がいます。
    ・if( val = 1 ){ ...
    ==を書き間違えたのか?、コードを記述した方しか、仕様なのかまったく分からないですよね。
    実際のデバッグ作業では、この不具合を特定するのに相当の時間を要するケースがあります。
    下のように書いたらどうでしょうか?
    ・if( 1 = val ){ ...
    コンパイルしてみると分かりますが、コンパイルエラーになります。
    勿論、==にすれば、正常にコンパイルできます。
    if文の定数は左辺に記述するように心がけていれば、こんなことはなくなりますね。
    心がけるだけで実際に書かなくても、だいぶ違うものです。

ページ先頭へ


ページ先頭へ

■データ圧縮
プログラムを作成していると、データが増えてきて、ROMが足りない!!ということになるケースがあります。そんなときは、データを圧縮してしまいましょう。
データにもよりますが、簡単な圧縮法、例えば、HUFFMAN圧縮でも、70%程度まで圧縮可能です。
圧縮法については、圧縮法入門を参照すると、沢山の方法が説明されています。プログラミングコスト、デバイスコストを見極めて最適な圧縮法を選択してください。
参考文献:C言語による最新アルゴリズム事典(技術評論社)

ページ先頭へ


ページ先頭へ

■演算を高速に
普通に演算を行うと、組み込み環境では、非常に時間がかかります。
そこで、以下のような方法を用いることで、高速化が可能です。
  • 2の倍数の場合の割り算
    1ビット右シフトすると、/2と同じです。2ビットだと/4、3ビットだと/8、つまり、2のn乗のnの分だけ右シフトすればよいわけです。
    ちなみに、掛け算の場合は、左シフトでOKです。
  • 2の倍数で割り算する場合の余りがあるかを判定
    通常だと、"%"演算子に相当します。割り算に似た考え方ですが、
    数字&(n-1)、但し、nは、割り算する数値
    結果がゼロならば、余りがゼロです。
  • 浮動小数点の演算
    組み込みで普通に小数点付きの数値演算を行うことは、一般的ではありません。
    多くの場合、他のメンバがライブラリとして用意していることでしょう。もしも、そんなことする必要があるの?という場合は、その人には聞かないほうが賢明です。教えてあげても良いでしょう。
    簡単な手法としては、必要な有効桁数だけ、ゼロを増やして、整数型で演算する。
    というのが、多いでしょう。
    以下に、例を挙げておきます。
    // child=1,parent=6,resolution=1000を指定すると、
    // 167が返ってくる
    // resolutionで割ると、0.167が得られる
    // 但し、child<=(ULONG_MAX/mag)でchildを指定すること
    // 上記条件を外れる場合、工夫が必要です。
    unsigned int int_div(
    	const unsigned long resolution,
    	const unsigned long child,
    	const unsigned long parent
    	)
    {
    	unsigned int d;
    	const unsigned long mag = (resolution<<1);
    	d = (unsigned)((child*mag)/parent);
    	return( (d+1)>>1 );
    }
      
    最初にresolutionを2倍しているのは、四捨五入するためです。


ページ先頭へ


ページ先頭へ

■条件マクロの多いソースを読みやすく
大きなプロジェクトでは、条件マクロが多くて読みにくい場合があります。
こんな時は、プリプロセッサを使いましょう。
gccだと、gcc -E -C ソースファイル名
でOKです。標準出力に表示されますので、必要に応じてリダイレクトなりすればよいです。
カレント以外の位置にヘッダファイルがある場合、-Iで位置を指定する必要があります。

ちなみに、UNIX用のEmacs系エディタ(WindowsならMeadow)では、リージョンを選択してから、M-x c-macro-expand を実行することで、表示できるので、非常に便利です。
場合によっては、.emacsに以下の記述をしないと動かないかも知れませんので、ご注意を。さらに、Windowsの場合は、Cygwinをgcc付きでインストールしておく必要があります。
(setq c-macro-preprocessor "cpp -C -E -Iインクルードファイルへのパス")
Windowsのメモ帳系エディタ(秀丸エディタなど)をお使いの方には、取っ付きにくいかもしれませんが、過去にMS-DOSでMIFESやVzを使っていた方なら、バリバリ使いこなせるはずです。実際私もそうでした。環境を整えるまで時間がかかりますが、一度はまると抜けられない感覚を味わえるかと思います。

ページ先頭へ

 
 
 
 

ページ先頭へ

■makefileの依存関係を自動生成
お知らせ makefileのページを作成しました。
makefileの基本を押さえたい方は、ご利用ください。
makefileの依存関係を手書きで書いているのをよく見かけますが、自動生成可能です。
多くのコンパイラ(実はプリプロセッサ)では、
  • -M
  • -MM
のどちらか、または両方が用意されている場合が多いです。
マニュアルでは、プリプロセッサの項目に記載されている場合が多いです。
一度、お使いのコンパイラのマニュアルを見てみては如何でしょうか。
マニュアル等に記載がない場合でも、使用できる場合もありますので、一度お試しを。
また、Windows環境でもCygwinを利用すれば、gccが使えますので、依存関係部分だけをgccに任せてしまう、という手もあります。
gccの場合、gcc -MM ソースファイル名
で依存関係が標準出力に表示されます。必要に応じてリダイレクトなりすればよいでしょう。
ちなみに、gccの場合、拡張子はデフォルトで.oになっていますので、他の拡張子にしたい場合は、sedとgrepを組み合わせればOKです。
sedはsオプション、grepはvオプションを使用します。
これを流用すると、特定のファイルを依存関係に含めないようにすることも可能になります。

参考書籍:
一押しは、Make―C programming utilityです。(make改訂版の新版のようです)
また、makefileとは無関係ですが、組込みソフトウェア開発における品質向上の勧め (コーディング編)もお勧め。最近バグの多い情報機器の開発者には是非とも読んでほしい一冊。

これで、ヘッダを修正したらmake cleanしてね、というのをしなくてよくなります。

自動化すると、以下のようになります(プログラム研究所より引用)

汎用的なmakefileの一例(単一ターゲット)
上のmakefileは、
  • SRC=で定義されたCソースファイル
  • HEADER=で定義されたCヘッダファイル
  • makefile本体
のどれかのファイルに変更があった際に、
TARGET=で定義された実行ファイルを作成する
makefileの一例です。

環境は、CygwinのGCC環境を想定しています。
他の環境の場合は、若干の修正が必要かもしれません。

一応汎用的になっていて、
Cソースが追加になったら、SRC=とOBJ=に追加
Cヘッダが追加になったら、HEADER=に追加
するだけで大丈夫です。
但し、
特定のファイルに対して別のオプションでコンパイルしたい場合は、
そのファイルに対して、別途ルールを指定する必要があります。

使用方法は、makefile冒頭部分に記述してあるとおりです。
基本的には、コマンドラインから、"make"とするだけです。
Meadow/Mule/Emacsなどでは、
ソースファイルやmakefileのウィンドウにフォーカスを当てて、
M-x compile として、ミニバッファで、make、と入力すればOK

余談になりますが、C++を扱う場合の注意点は
  • CFLAGSではなく、CXXFLAGSにコンパイルオプションを指定する
  • CCではなく、CXXにコンパイラを指定する
これらに注意しておけば、基本的にはCと同じです。

GNU makeの日本語マニュアルがCOOPさんの部屋にあります。
作者に感謝し、おおいに活用させていただきましょう。

それでは、makefileなどに振り回されることなく、
プログラム開発に時間を費やしましょう。


ページ先頭へ


ページ先頭へ

■ビットを扱う
C言語では、ビットが扱いにくい、とお考えの方が多いようですが、工夫次第では改善できます。ここでは、構造体と共用体を組み合わせた方法を紹介します。

// gcc -obitfield.exe bitfield.c -Wall

#include <stdio.h>

typedef struct sBitField
{
	unsigned char a :1;
	unsigned char b :1;
	unsigned char c :1;
	unsigned char d :1;
	unsigned char e :1;
	unsigned char f :1;
	unsigned char g :1;
	unsigned char h :1;
}BITFIELD;
typedef union uUniBitField
{
	BITFIELD bf;
	unsigned char ch;
}UNIBITFIELD;

int main(void)
{

	UNIBITFIELD un;

	un.ch = 0;
	printf( "bf=%02xd\n", un.ch );

	un.bf.a = 1;
	printf( "bf=%02xd\n", un.ch );

	un.bf.e = 1;
	printf( "bf=%02xd\n", un.ch );

	un.ch = 0;
	printf( "bf=%02xd\n", un.ch );

	return( EXIT_SUCCESS );

}
こうすると、1バイト全体、ビット単体の変更、参照が行えます。

ページ先頭へ



defineとconstの違い

TOP

defineとconstの違い
ソース

makefile
このサンプルは、マクロ定義の括弧ありなしでどのような結果をもたらす可能性があるかを示したものです。
結果は、makeして、実行していただくと分かるのですが、
  • 9
  • 5
となります。
一方、constを用いた例では、両方とも、同じ結果が得られます。
これは、双方の特徴を大きく表しています。
無用なトラブルを避けるためにも、定数定義は、constを使用したいものですね。
割り算と掛け算

TOP

割り算と掛け算についての考察
割り算と掛け算は結構、奥が深いものがあります。まずは、サンプルプログラムをmakeして、実行してみてください。
  • example1
    整数の普通の割り算、結構な時間ですね
  • example2
    同じことをシフト演算を用いて行いました。この中では、最短です。よく知られたことですが、2の累乗(n)で割り算は、nビット右シフトすることで、得ることができます。
  • example3
    実数の割り算です。整数の1.5倍かかっています。使いどころを誤ると、大変なことになります。
  • example4
    整数の普通の掛け算、割り算と比べたらかなり高速です。
  • example5
    割り算と同じように左シフト演算を使うと、掛け算が行えるという例です。普通の掛け算より、15%ほど高速です。
  • example6
    実数の掛け算です。整数の割り算:整数の掛け算の比率と実数の割り算:実数の掛け算、の比率が大きく異なるところが面白いですね。
まとめると、実数の割り算>実数の掛け算>整数の割り算>整数の掛け算>左シフト=右シフト、となります。このデータから、何が得られるでしょうか。よーく、考えてみてください。アセンブラソースが読める方は、make asm、として、ソースを読んでみると、納得できますね。
整数の割り算と掛け算の実行時間が1/4になることを考えると、いろいろと考えが膨らんできますよね。
ファームウェアでは、これらのことを踏まえて、例えば、温度管理を予め100倍してテーブル管理したりしています。これで、簡単な高速化になります。

makefile

TOP

まずは、このページで紹介するプログラムの共通makefileを紹介します。
話しを単純化するために、ヘッダファイル等は、なしの状態で makefileの"APL="に単一ソースを指定することにします。
状況によっては、Win32APIを使用するケースもありますので、 この場合のみ、-mwindowsを指定することにします。


ページ先頭へ

■コーディング規約
コーディング規約とは、複数人でプロジェクトを運用する際に、主にメンテナンスのしやすさを目的として、プログラムの書き方を取り決めしておくことを言います。
この取り決めを全くしておかないと、特にC言語の場合、自由度がかなり高いため、プロジェクトリーダの方が他のメンバのソースコードを読んでから、「これじゃ駄目」「常識的でない」などと勝手なことを言ったりするものです。プロジェクトに参加する際は、まず、コーディング規約の有無を確認しておいたほうが無難です。結構、ワンマンなプロジェクトリーダは多いものです。
できれば、組込みソフトウェア開発における品質向上の勧め (コーディング編)を読んでおくとよいでしょう。特に、最近バグの多い情報機器の開発者には是非とも読んでほしい一冊。
もうちょっとまとまったのが欲しいという方は、
組込みソフトウェア開発向けコーディング作法ガイド
組込みソフトウェア開発向けコーディング作法ガイド

文字通り、コ−ディング作法について記述した書籍です。
高品質なC言語コーディングのためには、開発者の暗黙の了解でコードを記述するのではなく、コーディング規約を定め、規約に基づいてコードを記述することが有効です。しかし、コーディング規約を制定するためには、C言語の文法に精通している必要があることなど、高いスキルと多大な労力が必要です。また、開発者への理解を深め、普及・徹底を図ることに大きな障壁があることも事実です。本書は、C言語のコーディング規約を策定している方を対象にした「コーディング作法ガイド」です。本書は、品質特性に対応して分類した作法と、それに対応するルール群から構成されています。コーディング規約を策定する方は、ルール群の中から必要部分を取捨選択することにより、目的に見合ったコーディング規約を策定することが可能になりました。
規約 書き方 備考




ページ先頭へ

■役に立つ書籍

(データ提供:Amazon.co.jp)

プログラミング作法(Brian Kernighan,アスキー)

¥ 2,940 通常24時間以内に発送
Amazonポイント:¥ 29
レビュー数:5
●良いプログラマになりたいあなたに
プログラムを書き始めると、どんな風に書くのが良いのか、
色々と戸惑うことがあると思います。
より良くするためにはどうしたら良いだろう? 自分の書き方は正しいだろうか?
そう考えたとき、周りに人がいれば訊くこともできますが、
その人が本当に正しいのかはわかりません。
また、自分一人だったらやっぱり解りません。
世界には色々と沢山のコードが転がっていますが、そのどれが正しいのかも解りません。

そんなときにはこの本です。
他のレビューにもありますが、プログラミングの正道が学べます。
読みやすく、効率的で、美しく、正しいプログラミングコードを学ぶことができます。
プログラマの心得などを知ることができます。

これを読まずに良いプログラマになることはできません。
是非、読みましょう。
●C言語の勉強で
C言語の勉強に適した1冊です。

ps.
20年ほど前の話で申し訳ありません。
最初にK&RのC言語の本で、C言語の勉強をしました。

すぐにはC言語でプログラムをうまく書くことはできなかったので、
UNIXのソースコードで勉強するようにしました。

最初はC Beautifierのソースコードを使っていました。
リカーシブコールを使うと単純な構造のプログラムになることがわかりました。

リカーシブコールは、場合によってはスタックオーバフロを招くので、
なんでも使えばいいものではないことをMISRA-Cを勉強して知りました。

本書は、MISRA-Cのような作法と、それ以外の作法を理解する、よい出発点となると思います。

自動車向けのように安全性が必要なシステムでは、メモリの利用量、計算時間が見積もりにくいリカーシブコールを使うことは原則として行わないMISRA-Cのようなプログラミング作法が大切なので、併せて関連書籍を読むとよいと思います。

日本語でもMISRA-C研究会から2冊参考資料がでているようです。
●1章だけで値段分の価値あり
第一章を読むだけで、自分のプログラムの書き方が大幅に変わるはずです。
当たり前の事ではあるが、その当たり前ができてない人のなんと多い事か、
と実感する事ができると思います。

「3日前の自分のプログラムは赤の他人が書いた物と思え」
こんなよからぬ格言をどこかしらで聞いた事があります。聞いた時は、「なるほど」
と思っていました。この仕事してる人は、こう考えている人も多いと思います。私もそうでした。
が、この本の第一章を実践するだけで、この言葉は私の頭の中から消えました。
何年前に書いたプログラムであろうが関係なくなるはずです。

将来こういう仕事に就きたい学生、職業エンジニア、どちらの人も読んだ方がいいです。

第二章以降は若干の専門知識を必要とします。
ハッシュの理論など、全く知らない人が読むと難解かもしれません。

著者のブライアン・カーニハンは、この他に「プログラミング言語C」という本を
デニス・リッチーと共著していますが、現在でも教科書として使える非常に有用な
著書を書いている人です。
●1章以外は、個別に専門の本を読んだ方がいい気がする
1章は大変参考になると思う。

長くプログラマをやっていると当たり前のことばかりが書いてあるのだが
実はこういったことを書いてある本は割りと少なく、言語の文法ばかりを
独学して、自分はわかった気になって態度の横柄な若者に、いつも言っている
お説教の要点がまとめてある感じなので、若いプログラマーは、文法を覚えたら
この本の1章を読んでおけば、お説教されることが少なく、好調な
社会人生活をスタートできるだろう。

それ以降は、それぞれの内容が広く浅いので、それぞれの分野の専門書を
読むべきだと思う。

非常にいらだたしかったのが、マルコフ連鎖の紹介で、業務を
やっていて、マルコフ連鎖を使うなどということはほとんどなく
興味が持てないのだが、後の章でも、マルコフ連鎖の章を読んでいることが
前提の説明が何度もでてくるので、興味がなくても、読まないと
いけないのである。

こうした本は、章毎に内容が独立して、各サンプルは短いコードで
説明され、必要箇所だけ読んでも理解できるように配慮されるべき
だと思う。
●プログラマ必読の書
本書の目的は"まえがき"にあるように、「質の良いコードを開発・維持する」方法を説明する事にある。位置付けとしては「プログラム書法」を時代に即して改変・増補したという所であろう。このため、「書法」時には存在しなかったC++, Javaを例題として取りあげているので、より実践的である。

コーディングのスタイルから始まり、アルゴリズムとデータ構造(Wirthのようだが)の決定、テスト方法、性能評価、移植性までプログラム開発における一連の流れを順を追って説明してあるので、流れに乗りやすい。Kernighanらの強みは、ベル研で多くの仲間と共に実践した結果を基に書いているので、机上の空論とは程遠い事である。

特に大規模プログラムの開発に携わる場合は、何らかの全体的方針が必要であり、本書は良い道標となる筈である。


パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法(,日経BP社)

¥ 4,200 通常24時間以内に発送
Amazonポイント:¥ 42
レビュー数:4
●解説が丁寧
単なるデザインパターンの説明だけの本よりは理解しやすいです。
どこもかしこも「デザインパターンを使えばよい」ということではなく、
「小さい金槌でこんこん叩けばいいところを大きな金槌を振り回すよう
な状況でデザインパターンを使うのはよくない」という内容の記述が
あり、はっとしました。
自分を含め、勉強したての人ほどついその傾向があるとおもいます。

じっくり読むことでリファクタンリグもデザインパターンへの理解も深まります。

●デザインパターンに違和感を抱いてる人にはオススメ
リファクタリング時に、こういう論拠で、こうしたら、
デザインパターンになりました、という具合に、
具体的なサンプルを通じて解説してくれます。

先人のノウハウの固まりだから、設計の段階から、
うだうだせずにデザインパターンを使おう、という意見に、
何となく違和感を感じている人には、
特に、読む価値のある一冊だと思います。

●シンプルで、読みやすいコードを。
~リファクタリング、という言葉を意識するようになったので、買ってみたのがこの本です。ぼくはデザインパターンはよく知りませんが、例をあげて丁寧に方法を示してくれています。本の中では、なぜリファクタリングが必要なのか、また、デザインパターンの適用の仕方を、筆者の経験を交えて説明してくれます。例として、問題のあるコードについて、一般的なデ~~ザインパターンの適用手順と、具体的な適用例を示してくれるのでとてもわかりやすいです。むやみにデザインパターンを適用するのではなく、状況にあわせてリファクタリングを行うことを教えてくれます。~
●良い設計はデザインパターンに行き着く
この本は、リファクタリングによって設計を改善して行く際に、デザインパターンのエッセンスを取り入れて設計を良くしていく道筋を取り上げています。

最初からデザインパターンを使うのではなく、リファクタリングによって、段々とパターンに近づけていく様を、「先輩とペアプログラミングしている」かのように読み進められます。

『オブジェクト指向における再利用のためのデザインパターン』、『リファクタリング』の両書を先に読んでおけば、本書の内容はすんなりと理解できるはずです。



珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造(Jon Bentley,ピアソンエデュケーション)

¥ 3,570 通常24時間以内に発送
Amazonポイント:¥ 35
レビュー数:5
●「プログラミング」と言う作業を見つめなおすのに最適。「設計する」と言う概念がよく分からない初級プログラマにも
昨今のソフトウェア開発においては大抵がRDBMSベースのもので開発ツールも整っており、
アルゴリズムや計算量、メモリ使用量およびそれらの結果としてのパフォーマンスなどを
真剣に考えないと全く仕事にならないケースと言うのはあまり無いと思われ、それはそれで
幸せな時代とも言える。

本書はそんな「幸せな時代」に逆行する形となるが、上記で述べた内容(アルゴリズム、
計算量、メモリ使用量、パフォーマンス)をメインテーマとしており、それぞれ

1)提示された問題の解法を著者の視点で説明
2)ソースコードとして具現化
3)ソースコードについて更なる考察
4)同じテーマでの練習問題の提示

と言うスタイルで記されている。
特筆すべきなのは問題を解くにあたって筆者が最終的なソースコードにたどり着くまでの
「思考」(いわゆる設計作業)が文章や擬似コードや図表で表現されている事である。
他のアルゴリズム関連の書籍では大抵いきなり完成形のコードが出てきてそれらを説明して
終わりと言うパターンが多く、それではただの丸暗記であり、初級プログラマにとって
本当の意味でのトレーニングにはならないと思う。

個人的な見解だが特に初級プログラマのステップアップの壁に一つには「設計と言う概念の
理解」が挙げられると思っており、本書はそんな概念を掴みきれていない初級プログラマにとって

あぁ、プログラマの頭の中ってこんな風に試行錯誤しながらコードを紡ぎだすんだ!

と言う感覚が味わってもらえるような造りとなっており、非常に好感が持てる。
練習問題が結構多いので勉強会のネタにも使えそうである。
理解しながら読み進めるのは意外と大変かもしれないが読み終えた時にあなたは
一皮むけたプログラマになっているはずである。
●納得!アルゴリズムは重要
「珠玉」ってなんて読むんだろう?興味を持ち、「本質を見抜く」というサブタイトルに惹かれました。プログラマーならば、アルゴリズムが重要であることは誰もが知っている、そしていくつかのアルゴリズムを知っていることだと思います。しかし本書を読むと、なぜアルゴリズムが重要なのか?どうすれば高速化できるのか?わかりやすくなるのか?メモリを減らせるのか?といった疑問が解き明かされていくのです。ページをめくる毎に”納得!”させられます。今までの漠然とした理解ではなく、本質を見抜いた理解に達すると、視界が開け非常に気持ちがいいものです。
だまされたと思って、一読ください。決して損はしません!!
●プログラマなら読むべき本
今までいろいろなアルゴリズムの本を見てきましたが、
ほとんどが理論的であり、眠気を誘うものばかりでした。

この本は、アルゴリズムが何であるか?データ構造とは?を
根本から解説しているのですが、プログラマであれば、
非常に興味をそそられる内容になっています。
サンプルプログラム等は、CやC++で書かれていますが、

他の言語しか知らなくても十分理解できるレベルです。

参考本情報が豊富にありますし、少しずつ読んで見ようと思います。

●アルゴリズムって何?
 今まで、アルゴリズム関係の本をいろいろと読んできた。しかし、この本は何なんだろう。自分ではベストだと思っていたアルゴリズムが、かなりの確率で否定される。

 「これ以上は無理かな?」と思っていた巨匠アルゴリズム+自己流アルゴリズムが、それ以上の高効率で処理されている。あるいは、「出来ないよ、そんなこと!」を「可能」にしている。まさに、「思い込み」は禁物だということを改めて感じさせてくれる、アルゴリズムにこだわる人には、まさに「目のウロコが落ちる」一冊。「速い」と「メモリを食う」は相反しないことに気づかされる。
 近年のコンピュータの高速化により、アルゴリズムの効率が無視されがちな企業プログラマには是非とも読んでいただきたい一冊。
 パズル的な面もあるので、アルゴリズムとパズルが好きな方は是非とも手に入れるべし!

●視点が変わる本です
この本は、プログラミング言語を学ぶという本ではなく、どのようにしてアプローチをしていくかという本です。たとえば、ある著名人は、よいプログラマーとは、机上でまず詳細設計を完璧にするものだといっていましたが、まさにその通りのことが書いてあります。

いきなりプログラムを書くのではなく、色々なアプローチからプログラムの骨格を作り上げていくことが出来る一冊です。
中堅プログラマーの方が、上級プログラマーになるためには必須の本だと思います。私のバイブルでもあります。



達人プログラマー―システム開発の職人から名匠への道(Andrew Hunt,ピアソンエデュケーション)

¥ 3,990 通常24時間以内に発送
Amazonポイント:¥ 39
レビュー数:5
●伝える事柄と伝える方法は車の両輪
伝える事柄さえ正しければ、伝える方法は何でも良いというのが間違いであることは、うすうす気がついていました。車の両輪というほど大事なものであることは、本書を読んで初めてきがつきました。そうだったんだ。
ヒント11: DRY Don't Repeat Yourself。

10 曳光弾
はずかしながら、読めませんでした。
ネットで探したら、「えいこうだん」とのことで、英語はTracer ammunition。
飛びながら光の軌跡を残す弾丸のことのようです。

どきっとしたのは「ヒント27:仮定せずに証明すること」。
しまった。やられたと思いました。星5つ。
●素人から玄人への道
インパクトのあるタイトルと黒々とした表紙から、ギーク向けの本と思ってました。
が、読んでみるとソフトな内容。
プログラマとして知っておくべき、気をつけるべき、そして実践するべき内容が上手くまとめられており、「そうそう、そうなんだよねー」とウンウンしまくり。
もっと早く読めばよかったという気もするが、若い頃に読んでも実感が湧かなかったろうな。
挿入されているお話も面白く、新人研修などの講師になったら話のネタに使えそうだわ。
(生徒がこの本を読んでいませんように・・・)
●知らないと恥ずかしい
もっと早く読むべきだったと後悔しています。
達人の仕事振りを説いた1冊です。

この本のキーワードとなる言葉は、
1、割れ窓をなくす
2、蛙の煮物
3、伝達しよう
4、DRY原則
5、直交性
6、自動化
7、絵画の制作のやめ時を知る

プログラマーでこの本を読んでいなかったら、
急いで読みましょう。
それ位、知らないと恥ずかしいです。
●新人プログラマに読ませたい
この本には、プログラミングの原則が、詳細かつ分かりやすく記述されている。
それらは、プログラミングをする上での、ごくごく当たり前の事柄なのだが、意外に実践できていなかったりする。

新人プログラマなど、とりあえずは動くものが作れるが、品質がいまいちな人たちに、最も読んでほしい本である。
●初級PGから上級PGになるための本
 達人とあるので、上級者向けと思われがちであるが、内容は、初心者から脱し、中級、上級者への移行途中の方が読まれると良いです。 私は、すでに上級レベルに達した後に読みましたが、これを若い頃に読んでいれば、もっと楽に上達できたのでは無いかと思います。 テクニックと言うより、考え方、創造力を磨く事が出来る書籍です。


プログラミング言語C ANSI規格準拠(石田 晴久,共立出版)

¥ 2,940 通常24時間以内に発送
Amazonポイント:¥ 29
レビュー数:5
●解説書より実践的思想書だと思いましょう
 不親切だとか、あいまいな記述が多いとか、時代遅れとか不評の本書ですが、それらは全くもって事実です。しかし、本書は解説書とか入門書の類ではなく、設計者自身によるC言語の設計思想に触れるための本です。

 あるアルゴリズムを書くにあたって、C言語の設計者ならどうするだろうかということがわかります。

 実用的な入門書は他にたくさんあります。
 C言語学習者が必ずつまずくポインタに関しては「C言語ポインタ完全制覇 (標準プログラマーズライブラリ)」をおすすめします。
●ある程度C言語に慣れた人が知識補強のために読む
基本的に説明がわかりにくく、しかも時代遅れの部分が多いため、
まず初心者にはまったくお勧めできないことは間違いありません。
ある程度のC言語の知識を前提としているC言語解説書です。
サンプルはポインタを乱用したりトリッキーな書き方をしたり
しているプログラムが多く、正直ほめられたものではありません。
しかし、この薄さでC言語の全機能をほぼ網羅しており、
しかも(誤訳を除けば)ほとんどウソが書かれていないのは評価できます。
※他の書籍(特に初心者向け)は結構ウソが書かれている
C言語にかなり習熟した人が薄くて持ち運びやすいリファレンスとして持ち歩くのならばお勧めできます。繰り返しますが初心者は読まないように。
●初心者に読ませてよいか、ちょっと迷うが…
この本を薦める場合、相手が秘めた力量を十分に計る必要があると思う。
ど素人同然の人に押し付けても、たぶんプログラム嫌いになると思う。
イケそうだな…と思った相手なら、グングン伸びてくれるだろう。

char型は符号付きか符号なしか?そんな重要なことが、超あっさり書いてある本である。
●古典的教科書
いまとなっては古く実用的ではないかもしれませんが、
C言語が持つ文化的背景を知るために読んでおいても損はないと思います。
●Cコンパイラのソースを読もう
最初にC言語を覚えるときに、この本の初版を読みました。

Hello Worldのプログラム例は、UNIXプログラミングとしては最適だと思います。
しかし、関数でプログラムを書くという視点では疑問に思いました。
main, printfは、C言語関数として例外の代表例だからです。

関数でプログラムを書くということは、試験を単純にしたいという要望があるからではないでしょうか。
Hello Worldから、単体試験プログラムが書けるようになるには、長い道のりが必要かもしれません。

自分では、C Puzzle BOOKとCプログラムの落とし穴の2冊で勉強しました。
その後、SaferCとMISRA-Cを読んで愕然としました。

きちんと問題を解決しようとしている人がいることを知り恥ずかしくなりました。
Code Complete, Code Readingも推奨できます。

ps.
日本語しか知らなければ、日本語の文献に頼るのは仕方がありません。
C言語は英単語でできていることを知ったときから、できれば原典にあたるような習慣を身につけるとよいかもしれません

この本も、英語で読むと、日本語で読んだとき以上の知見が得られるかもしれません。

プログラマは兎角、自然言語が下手だと言われてます。
それはそれで仕方がないことではないでしょうか。

C言語プログラマでCコンパイラのC言語のソースコードを読めない方が、プログラマ失格ではないだろうか。

GCCはじめ、ソースコードを公開しているCコンパイラのソースコードを読みながら、本書に書いてあることを確かめるとよいのではなだろうか。


Code Complete第2版〈上〉―完全なプログラミングを目指して(Steve McConnell,日経BPソフトプレス)

¥ 6,405 通常24時間以内に発送
Amazonポイント:¥ 64
レビュー数:5
●プログラマになるつもりなら、まず読もう
プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。

goto文論争など基本的な情報の資料にもなっています。
すでにプログラマになっている人は、C言語プログラマだけに限らず、多くの方が読まれているとよいと思います。
会社が、本当にプロを養成するつもりなら、必ず読めというと思います。
会社が、読む時間を工面してくれるはずです。

会社が、一時的な金儲けだけを目指している場合には読めと言われないかもしれません。
プロとしての仕事を目指すのではなく、顧客の対応の時間を重視しているなら、読む時間を工面してくれなかもしれません。

そういう場合は隠れて読んで、3年たったら別の会社に行くのがいいかもしれません。
いずれにしても、プロとしてプログラムに向き合う時に必要なことがいろいろ搭載されています。

ps.
最初は全部理解しようと肩肘はらずに、気軽に読み進んだ方がいいかもしれません。
仕事で関係がありそうな話題になったときに、もう一度読み直してみましょう。
●初心者に
かなり評判がよかったので買ったのですが、みながそこまでべた褒めするほどでは
ないと感じました。
第1版も見ることができましたので、見てみたところ、
第1版の方が絵も多いし、訳もよく、説明も分かり易いです。残念なことに。
第2版だと、後半は【下巻】に収録されているので両方買うとかなり高額になります。

初心者の方にお薦めします。
上級者の方が読んでも、自分のやっている作法の正しさを確認するだけになるでしょう。スランプの時にどうぞ。
●入門書でありながら奥が深い
会社に入るなり、上司から「これをまず読みなさい」と渡された一冊。
基本的な内容でありながら、今読み返しても学ぶことが多い。
今年の新人にもこの本を渡したが、彼らにもやがて部下が出来た時に、その部下に渡してもらいたいと思う。

高い値段に見合う一冊。
プログラマなら必携だと思います。
●美しいコードを
本の厚さと、上下巻というボリュームで、
なかなか手を出せずにいた本ですが、
読んでみるとスラスラとあっというまに読み終えました。

美しいコードを書くのは永遠のテーマですが、
沢山のヒントが所狭しと書いてあり、感動しました。

もうこの本無くてはコーディングできません。

プログラマを語る以上は、この本は読んで置くべきです。
●これは理解できないとヤバイです。
読んだことのない第1版と、基本は変わってないのかも?と想像しました。
実経験と重なるプロジェクト/システムは、後から参入でも非常にやり易かった。
全く重ならない所は言うまでもなし。

どうも、この本に書いてあることを理解できない、知らない、経験ない人は、
変なプロジェクト体制、変な設計、変な実装しても問題の本質を理解できない
ようです。

きついこと書きますが、この本の内容を理解できない人は、正直言って
この業界辞めた方がいいと思います。
実践は・・・できるところで働きましょう。


Bruce EckelのJavaプログラミングマスターコース〈下〉徹底探究!Javaのしくみとオブジェクト作法(Bruce Eckel,ピアソンエデュケーション)


レビュー数:2
●リファレンスに
コレクションやスレッドについて非常に詳細にかかれています。
リファレンスに是非一冊手元に欲しい本です。
内容は少し難しいので中級者以上向けでしょう。
また、翻訳のせいで所々おなかしな日本語があり、理解に苦しむところもあります。が、内容は非常に深くて役に立ちます。
●Javaに慣れてきた頃に最適
スレッド、ネットワーク等の比較的に高度なもの、デザインパターンなどUMLとの絡みなど初心者を脱してきた頃に使うものがたくさん載っていてかゆいところに手が届きます。

Javaをある程度やってきていて、この本を買ってから1年以上たちますが今でも開発する際に手元においておいています。概念だけでなく実例も載っているためリファレンスとして使うにはとてもいい本です。JavaをCOMとして使うなど全く知らなかったことも載っていて得るもが多かったです。



プログラム書法(,共立出版)

¥ 3,150 通常24時間以内に発送
Amazonポイント:¥ 31
レビュー数:5
●アセンブラ出力を知ろう
第一版のまえがきに「よいプログラミングのしかたは、一般論を述べたてることによって伝えられるようなものではない」と書かれている。

そのことを肝に銘じて、全体を読んでみると、いろいろな知見が得られた。

どんな関数型プログラミング言語も、機械語になれば、機械語のジャンプ命令(GOTO命令)に置き換わるのであるため、ここで指摘しているプログラムの例を、実際にコンパイラでアセンブラに変換して、その意味を理解するようにするとよい。

アセンブラ出力を比較できるようになると、コンパイラスイッチによる動作の違い、処理結果の違いを理解できるようになるだろう。

例題は、FortranまたはPL/1で書かれているため、これらの言語を知らない人には馴染みが薄い部分があるかもしれない。
しかし、FortranとBASICは数値計算においては姉妹のようだし、FortranとCとは関数定義する言語としては兄弟のようなので、BASICまたはCが理解できる人なら、難なく理解できると思う。

プログラムの基本は、ずっと同じであり、FortranもC言語も関数を定義できる言語としては同じように理解してもよいのではないだろうか。

●古典的名著
プログラムが大規模になるに連れて、それまでは個人の職人技で書かれていたプログラムを何とか系統的な手法で開発できないかという試みがなされた。それが、本書でも述べられているHoare, Knuth等が提唱した「構造化プログラミング」の手法である。

例として使われる言語はPL/I, COBOLと時代を反映して古いが、考え方は現在でも通用する。逆に構造化プログラミング機能を持たないこのような言語で「構造化プログラミング」の概念を説明する事によって、C, C++, Javaのような言語が何故生まれて来たかを知る事になって、意義があるとも言える。

なお、本書の訳者は東工大の木村教授(当時)だが、本書で用いた「書法」という題名を、「プログラミング言語 C」(著者 Kernighan&Richie)を訳した石田晴久氏が副題で用いているのは因縁めいていて面白い。
●一度は熱心に取組んで欲しい歴史的著作
パソコンの普及と共に、興味があれば誰でも本格的にプログラミングを行えるようになった。
そのような中から優れたプログラマも数多く出てきたのだが、職業としてプログラムを行う人でさえ、救いようのないプログラムを書く者が沢山いるのも事実である。
優れたプログラマが、そんな「ひどい」プログラムを見ると、強い不快感や嫌悪感など非常に嫌な気分に襲われる。そこで、それを書いたプログラマを注意すると、「何がいけないのですか?ちゃんと期待通りの処理をしますよ」と言われたりする。その「何がいけない」を実例で検証しながら、極めて明快に解説してくれるのが本書である。
例外処理はどこに置くか?マルチif分はどんな条件を先に吟味するか?など、なんでもなく思えるものにも、合理的なものとそうでないものでは雲泥の差があり、プログラマが予想もしなかったトラブルに発展するのを妨げてくれる法則がある。
本書では古い言語を使っているが、それらの言語を知らなくても、読むのに支障はない。そして、実際に使っているのが、アセンブリ語だろうが最新のオブジェクト指向言語であろうが、基本は全く変わらない。
賢いプログラムを書けるようになることで、思考能力そのものも論理性を持つようになり、設計においてさえ、良い影響をもたらすに違いない。
一度は熱心に読んで欲しい歴史的なテキストである。
●プログラミングの基礎文献の一つ
英語でのWRITINGの本で「The Elements of Style 」という古典的名著
があるが、原題を見ても判るように、この本はそのプログラミング版。
言わずもがなのことながら、例は古いがこの本はFortlanやPL/Iを学ぶ
ための本ではなく、適切なプログラミングスタイルを学ぶのが主眼なの
で気にするほどのことでもない。それに、C++やJAVAと違い、そんなに
難しい言語ではないので、知らない人でも何が書かれてるか大体のこと
はわかると思う。それに、ここに書かれている内容は特定言語に特化し
たスタイルではなく汎用的・普遍的な内容なので、どんな言語にも応用
可能である。実際この本にインスパイアされたプログラム書法本は数知
れずある。
●古典的名著
プログラミングのアンチパターン集として、古典的名著です。
対象となっているプログラミング言語はFORTRAN, COBOL, PL/Iと古いのですが、その内容は現在でも充分に通用するものです。
ぜひ一度、目を通されてはいかがでしょうか?


サバイバル MS‐Windows マクロプログラミング作法 (アジソン ウェスレイ・トッパン情報科学シリーズ (54))(Woody Leonhard,トッパン)



Warning: Invalid argument supplied for foreach() in /virtual/kommy/public_html/inc/func.php on line 75


図解 C言語構造化プログラミング作法 (HBJ integrated libraries)(,HBJ出版局)



Warning: Invalid argument supplied for foreach() in /virtual/kommy/public_html/inc/func.php on line 75

ページ先頭へ




■お知らせと連絡先

このウェブサイトで取り上げて欲しい話題や分かりにくい点などありましたら、
以下のメールアドレス宛にメッセージをいただければ、参考にさせていただきます。

メールアドレスは、work_komiあっとまーくyahoo.co.jpです。
(「あっとまーく」は、半角英数のあっとまーくに変換してね。)

また、XBOXをお使いの方は、ゲーマータグ(akbox)にてフレンドリクエストを受け付けています。