A君とB君の結果が異なったのは、「外部入力ファイルの中の改行コードが異なっている」ためです。
このプログラムの問題点は、改行コードとして「CR+LF」を前提としていることです。問題文を読んで、「同じソースコードなのに振る舞いが違うということは、動作環境が同じでない可能性があり、改行コードが怪しい」と思った読者は正解です。コンピュータの改行コードは、CR(キャリッジリターン)とLF(ラインフィード)で表します※3)。
今回のプログラムでは、テキストファイルを一文字ずつ読み出し、CRとLFが順番に来た場合、行数をカウントする仕組みです。ですが、別の改行コード、例えば「LF」が設定してあると、CRがいつまでたっても来ないため行数をカウントできず、列数も0クリアできません※4)。
※3)CR、LFという言葉は、タイプライターから来ています。タイプライターは、キャリッジと呼ぶ紙を固定する機構に、紙を差し込んで文字を打ちます。紙を固定してキーを打つと1文字を印字し、紙が自動的に1文字分右側にずれます。紙が行の最後に来るとベルが鳴り、タイピストは手で紙を行の先頭に戻して、紙を1行下にずらします。つまり、紙を行の先頭に戻すことを「キャリッジリターン」、紙を1行下にずらすことを「ラインフィード」と呼びます。ちなみに、キーの並びがアルファベット順でないのは、特定の指が疲れないようにするためとのこと。なお、一番上の段の文字だけで「typewriter」と打てます。
※4)昔、顧客先でプログラムの動作確認をしたときのことです。開発担当でないエンジニアが現地で外部入力ファイルを作成し、プログラムを実行したところ、正しい結果になりません。エンジニアはソフトウェアのバグだと思い、ソースコードを何度も細かくチェックしましたが、バグは見つかりません。エンジニアはその結果を開発者に報告し、原因を調査するように依頼しました。数時間後、開発者から来た回答は、「ソフトウェアのバグではなく、改行コードか文字コードが違っているので、修正してください」でした。
仕様をもう一回確認してみましょう。以下の文面が書いてあります。
(2-3-4)テキストファイルから入力した文字が、改行表すLF(ラインフィード)、その1つ前の入力がCR(キャリッジリターン)の場合は、行数+1、列数=0とし、(2-3-1)を実行する。
つまり、改行コードが、「LF」か「CR」しかない場合、行数のカウントと列数のクリアができません。今回の問題では、B君はA君のプログラムをそのままコピーし、入力データのファイルで、改行コードを「LF」にしたのが原因でした。「再利用」する場合、きちんと内容を理解していないとうまくいきませんね。
改行コードは、OSやテキストエディタの設定に依存します。例えば、Windowsの改行コードは基本的に「CR+LF」、Linuxは「LF」です。Macの昔のバージョンは「CR」だったようです。もちろん、改行コードの設定はテキストエディタ側で変更できます。
これと同じような動作不良はよく聞く話ですが、自分のプログラムで起きると、原因がなかなか分かりません。仕様書に改行コードを明記していることが少なく、書いてあっても、開発者は見ないことが原因でしょう。改行コード以外にも、文字コードでも不整合が起こることがあります。インターネットの黎明期に、Webサイトを閲覧すると、ブラウザの設定によっては、大量の文字化けを起こし、びっくりした人が多いはずです。
今回の自己採点シートを下記に示します。
問題 | 内容 | 配点(点) |
---|---|---|
ファイル検索の問題 | 5分以上考えた | 50 |
データファイルの改行コードが異なることが分かった | 50 | |
上記以外のバグを見つけた | +α | |
リスト5 自己採点シート |
バグはいろいろな成果物に潜んでおり、原因が分からないと不思議な現象に思えます。今回は、改行コードに着目した問題を出題しました。実行結果が正しくない場合、ソースコードのバグを探しますが、外部入力のファイルのデータが原因ということもありえます。このバグは意外に少なくありません。仕様をしっかり確認しましょう。
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.