CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
CX-Checker はC言語ソースプログラムを解析して コーディング規約に違反している部分を検出するためのコーディングチェッカーです。 カスタマイズによって開発チームごとのオリジナルルールもチェックできる点が大きな特徴です。
今月、私の下に初めての部下がつくことになりました。ただし、日本語は「コニチワ」レベル、英語は何とかしゃべれる東南アジアからの留学生です。やることはC言語によるコード書きとバグ修正で、彼(留学生)はプログラムの基礎(ロジック・構造)は他の言語で既習で、C言語の鬼門であるポインタについては昨週1週間かけた講義で理解できたようです。ちなみに私の英語力は「ゆっくりなら読める・書ける・リアルタイムにしゃべるのは苦手」の典型的日本人英語です。(コミュニケーションは互いの片言以上会話以下の英会話(w)かe-mailで) 今後、コード書きをさせるのに「そこはstrtok使って。使い方はテキスト・関数辞典見て調べて」等の指示で仕事をまわしたいのですが、その『テキスト』を何にするかで躓きました。いままで私がC言語を学んだのは日本語で書かれたテキスト・関数辞典でした。これらは留学生の彼には参考になりません。英語
TEFでもTDDや単体テストの話題で持ちきりですが、 極力ユニットテストを書かずに品質を確保する方法 by ひがやすを blog やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 後述にもありますが、「ユニットテストは工数がかかる」という意見に対する対案のようなもので、せっかく書いたテストコードをより効果的・効率的にするための工夫ですね。 事実、ここ数年、「ユ
concov のドキュメントを書こうと思ったけれど、何から書くか困ったので、とりあえずその前に gcov の使い方とはまりどころを書いてみます。 gcov とは C 言語で書かれたプログラムのカバレッジを測定するツールです。gcc に付属しています。 基本的な使い方 こういうコードがあるとする。 /* test.c */ #include <stdio.h> int foo(int x, int y) { return x + y; } int bar(int x, int y) { return x - y; } int main(void) { printf("%d\n", foo(2, 3)); printf("%d\n", foo(3, 4)); return 0; } コンパイルする。-coverage をつけると gcov 用のオブジェクトファイルが生成される *1 。 $ g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く