ワーニング(警告)を軽微な記述ミスと無視せず、致命的なエラーだと考えて、必ず対処しましょう。今回のワーニングの例を図1、図2に示します。
図1は領域外書き換えのワーニング、図2は筆者がやってしまったバグのワーニングを示しました。バグのヒントはワーニングに隠されているかもしれません※2)。まずは十分、分析しましょう。
※2)筆者の研究室にいた学生が、卒業後、ワーニングに関するエピソードを教えてくれましたので紹介します。数値計算関連のプログラムを作成していたときに、プログラムを実行すると、ビルド構成(リリースビルド、デバッグビルド)によって、実行結果が毎回変わるバグに悩まされていました。
先輩エンジニアに相談したところ、その先輩は、事象を確認し、プログラムを実行した後、すぐにコンパイラのワーニングを見始めました。すると、無視していたワーニングの中に、修正が必要なワーニングが含まれていました。そのワーニングを修正したところ、ビルド構成の違いにより実行結果が変わることはなくなったそうです。
無限ループは、非常に特徴的なバグです。強制終了するまで、繰り返し同じ処理を実行し続けるような場合に疑いましょう。無限ループ発生時には、フラグ変数の設定ミス、代入記述のミス、switch文のbreak抜けなどを疑うとよいでしょう。大きな状態遷移を扱うプログラムでは、このバグが潜んでいる可能性があります。
領域外を書き換えると、環境によっては、プログラムが停止することがあります。もちろん、その他のバグかもしれませんので、バグの候補の一つとして考えてください。
今回取り上げたコーディングのバグの対策には下記があります。
静的解析ツールを使用すると、この「よくあるバグ」を見つけられます。
初心者のうちは、少しずつ確認しながら実装を進めましょう。例えば、複数個の条件分岐のブロックができたら、デバッガなどで条件分岐を確認するといいでしょう。少し面倒に思いますが、後々苦労しないため、小さい範囲で確認しましょう。
コーディングのバグは、単純バグの場合がほとんどですが、プログラムを結合して実行すると、不可解な挙動をします。今回紹介したバグは、皆さんにとっては既知のバグでしょうが、数あるバグの一つとして、再度、思い出していただければ幸いです。
今回のバグは、拙著「ソフトウェア技術者のためのバグ検出ドリル」(日科技連出版)でも取り上げています(電子版、書籍版の両方で)。興味がある方はご参照ください。
本シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の新刊「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から発売されました。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しました。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.