条件付コンパイル用識別子の管理方法、コンピュータプログラムの作成支援装置及びプログラム
【課題】
条件付コンパイルの識別子のスペルミス、設定ミスを低減する。
【解決手段】
コンピュータが、プログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する。ユーザは、識別子一覧を参照して、出現回数と定義状態を確認し、必要に応じてソースコードの修正作業を行う。更に、ユーザが前記識別子一覧から任意の識別子を選択することによって、コンピュータは、条件付コンパイル用の識別子の設定を受け付けて、条件付コンパイルのコマンドを生成する。
条件付コンパイルの識別子のスペルミス、設定ミスを低減する。
【解決手段】
コンピュータが、プログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する。ユーザは、識別子一覧を参照して、出現回数と定義状態を確認し、必要に応じてソースコードの修正作業を行う。更に、ユーザが前記識別子一覧から任意の識別子を選択することによって、コンピュータは、条件付コンパイル用の識別子の設定を受け付けて、条件付コンパイルのコマンドを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムソースコード（以下、ソースコードという）に含まれる条件付コンパイル用識別子の管理方法、コンピュータプログラムの作成支援装置及びプログラムに関し、特に、識別子のスペルミスを検出して条件付コンパイル（Ｃｏｎｄｉｔｉｏｎａｌ Ｃｏｍｐｉｌａｔｉｏｎ）を確実に行うことのできる識別子の管理方法、コンピュータプログラムの作成支援装置及びプログラムに関する。
【背景技術】
【０００２】
近年、アプリケーションが多機能化・多品種化しているため、それに比例して、プリプロセッサ命令（コンパイル前にソースプログラムに対して行われる前処理命令であり、文字列の置き換えやプログラムの有効／無効部分の指定が可能である）を用いた前処理が多用され、また、ソースコードも大規模かつ複雑になっている。またそのため、デバッグ作業は複雑になり時間がかかっているのが現状である。特許文献１には、ソースコード中のプリプロセッサ命令を解析し、その結果をエディタ画面に視覚的に表示する機能を備えて、プリプロセッサ命令の間違いを検出できるようにしたプログラム・エディタが紹介されている。
【０００３】
また、特許文献２、３には、ソースコード入力作業中に、入力ミスの可能性のある箇所を強調表示することのできるエディタが紹介されており、特許文献４には、プログラム中で使用されている変数の整合性チェックを行う変数データ処理装置が紹介されている。
【０００４】
図１５は、従来のプログラム作成手順を示したフローチャートである。図１５を参照すると、まずエディタなどを用いてプログラムの作成・編集を行い（ステップ１−１）、必要な箇所に条件付きコンパイルの設定が手動で行われる（ステップ１−２）。この条件付きコンパイルの設定は、機種依存性がからむ場合やデバッグ時に多用され、プログラマがソースコードや設計書から判断して、必要な箇所に条件付コンパイル用プリプロセッサとその識別子を設定することによって行われる。
【０００５】
続いて、コンパイルが行われる（ステップ１−３、１−４）。図１６は、条件付きコンパイルのコマンド例であり、この場合、ソースコード中の条件付きコンパイル用プリプロセッサ命令に後続して用いられている識別子”ＤＥＢＵＧ”、”ＴＥＳＴ”が有効化され、例えば、ソースコード中の＃ｉｆｄｅｆ ＤＥＢＵＧの行から、＃ｅｎｄｉｆまでの部分がコンパイルの対象となる。このコンパイルの過程で、エラーのチェックが行われるが、ここで文法上のエラーがある場合は、コンパイラがエラーを表示する（プリプロセッサ命令自体の入力ミス等の文法エラーも含む）。そして、エラーと表示された場合は、再びプログラムの修正に移る（ステップ１−１）。一方、エラーが無い場合にはデバッグ作業に移る。
【０００６】
次のデバッグ作業では、さまざまな評価を行い、プログラムが仕様書通りに動いているか評価を行う（ステップ１−５、１−６）。ここで、誤作動に気が付けば、様々なツールを使用したり、実際にソースを読むことにより、プログラムの論理的なエラーなどを発見して、ソースコードの修正に移る（ステップ１−１）。エラーが発見されなかった場合は、プログラムの作成は終了になる。
【０００７】
【特許文献１】特開２０００−１４８５０８号公報
【特許文献２】特開平５−３４１９７６号公報
【特許文献３】特開平１１−７３３０５号公報
【特許文献４】特開平７−７８０７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
条件付コンパイルで用いるプリプロセッサ命令に後続する「識別子」として、任意の文字を定義可能であって大変便利であるが、その反面、プリプロセッサ命令を含む行は文法的に独立したものと取扱われるため、以下のような負担が生じていたといえる。第１の問題点は、コンパイル時のエラーチェックでは、たとえ入力ミスであってもそのような識別子が設定されているものと判断され検出できないことにある。例えば、図１６のように、コンパイルコマンドで「ＤＥＢＵＧ」と指定したのに対し、ソースコードでは識別子「ＤＥＢＡＧ」（入力ミス）が定義されていたとしても、コンパイラは誤りとせず識別子「ＤＥＢＵＧ」の条件付きコンパイルを行う。このように、識別子の入力ミスは、デバッグ作業でしか発見することができず、条件付きコンパイルの識別子のスペルミスの不具合が発生すると、デバッグ作業を強いられることになり、大規模かつ複雑なソースコードではかなりの負担となっている。
【０００９】
第２の問題点は、条件付きコンパイルの識別子を指定する際に、多くの識別子の設定を手動で行う必要があるため、同一の識別子が指定されるべきところ、別の識別子が設定されるなど、見落としや指定間違いが発生する危険性が常にあったことにある。大規模なソースコードは、複数の人間がプログラミングしており、更には、一つのソースコードで多くの品種・バージョンに対応するため、複雑に条件付きコンパイルのプリプロセッサ命令が指定されている場合もある。また、ソースコードが大規模で複雑であれば、条件付きコンパイルが正しく設定できているかどうかを検証することも困難となり、プログラム開発作業の効率化を阻害する要因ともなっている。
【００１０】
この点、特許文献１は、プリプロセッサ命令の解釈結果を編集画面上に視覚的に表示するものであるから、デバッグ作業の軽減にはなったとしても、大規模かつ複雑なソースコードでは上記各問題点を根本的に解決するものとはならない。また、特許文献２、３の技術をもってしても、条件付コンパイル用の識別子の場合、何をもって入力ミスと判定するかどうかも一義的でなく適用が困難である。また、特許文献４に記載の技術も、インタプリタ系言語に特有の変数の整合性をチェックするためのものであり、この種の問題は、コンパイラ系言語では、コンパイル時に検出することが可能となっているものである。
【課題を解決するための手段】
【００１１】
本発明の第１の視点によれば、少なくともコンパイルする前の段階で、コンピュータが、プログラムソースコードを走査して、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示し、ユーザに注意を喚起することのできる条件付コンパイル用の識別子の管理方法が提供される。
【００１２】
本発明の第２の視点によれば、上記した条件付コンパイル用の識別子の管理方法において、少なくともコンパイルコマンド入力時に、前記コンピュータが、前記識別子一覧からユーザによって選択された識別子を、条件付コンパイル用の識別子として設定すること、を特徴とする条件付コンパイル用の識別子の管理方法が提供される。
【００１３】
本発明の第３の視点によれば、上記したソースコード中の識別子の管理方法を実施するためのコンピュータプログラムの作成支援装置、及び、コンピュータに上記ソースコード中の識別子の管理方法を実施するためのコンピュータ・プログラム（チェッカ・プログラム、プログラム作成支援プログラム）が提供される。
【発明の効果】
【００１４】
本発明によれば、少なくとも出現回数と定義状態を併記した識別子一覧を参照して、識別子のスペルミスや不整合を発見することが可能となる。
【発明を実施するための最良の形態】
【００１５】
続いて、本発明を統合開発環境（Ｉｎｔｅｇｒａｔｅｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｎｖｉｒｏｎｍｅｎｔ）に適用した本発明の好適な実施の形態について、図面を参照して詳細に説明する。図１は、本発明に係るコンピュータプログラムの作成支援装置の概略構成図である。図１を参照すると、コンピュータプログラムの作成支援装置には、ソースコードやオブジェクトコードを記憶保持する記憶装置１１、後述する動作を行う識別子一覧出力部１２及び識別子入力受付部１３、コンパイラ１５（これらは、コンピュータのハードウェア資源利用するコンピュータプログラムで構成され、前２者については後に詳述する。）、識別子一覧を表示するためのモニタ１４とのほか、図示しないエディタ、デバッガ等プログラミングに必要なツールが統合して扱えるような環境が整えられている。
【００１６】
図２は、識別子一覧出力部１２で管理される識別子一覧作成用のテーブル構成を表した図である。図２を参照すると、ＩＤ（通し番号）、識別子名（文字列）、出現数（ソースファイル中の出現回数）、設定（使用＝ＯＮ／不使用＝ＯＦＦ）、定義、強調表示（ＯＮ／ＯＦＦ）といったフィールドが設けられ、ＩＤで識別される識別子の情報を格納可能となっている。また、定義フィールドには、ソースファイル中にその識別子を定義している部分がないことを示す「ＯＦＦ」、ソースファイル中にその識別子をプリプロセッサ命令＃ｄｅｆｉｎｅで定義していることを示す「ＯＮ（Ｄｅｆｉｎｅ）」、ソースファイル中にその識別子をプリプロセッサ命令＃ｕｎｄｅｆで定義していることを示す「ＯＮ（Ｕｎｄｅｆ）」、ソースファイル中にその識別子をプリプロセッサ命令＃ｄｅｆｉｎｅ及び＃ｕｎｄｅｆで定義していることを示す「ＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）」が記述される。識別子一覧出力部１２は、このテーブルの適宜項目を選択・表示してユーザに提供する。
【００１７】
図３は、上記した識別子一覧のテーブル構成中の定義欄の４つの状態を求めるためのマトリクスである。図３を参照すると、ソースファイル中にその識別子が＃ｄｅｆｉｎｅで定義されている場合に、ｄｅｆｉｎｅ＿ｆｌａｇが１となり、＃ｕｎｄｅｆで定義されている場合に、ｕｎｄｅｆ＿ｆｌａｇが１となり、これらの組合せによって、上記ＯＦＦ〜ＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）までのいずれかの状態を求めることが可能となっている。
【００１８】
図４は、本発明を適用した場合のプログラム作成の大まかな流れを示したフローチャートである。図４を参照すると、プログラムの作成・修正が終了したら（ステップ３−１）、識別子一覧出力部１２がソースコードから条件付きコンパイルの識別子一覧を作成する処理を実行する（ステップ３−２）。
【００１９】
次いで、モニタ１４に出力された識別子一覧表（図１１参照）より、適宜強調表示された識別子を確認して識別子にスペルミスや不整合があるかを確認し（ステップ３−３、３−４）、スペルミスが存在する場合は、再びプログラムの作成・修正に戻る（ステップ３−１）。一方、識別子にスペルミスがない場合には、識別子一覧表から、有効にする識別子を選択する（ステップ３−５）。例えば、図１２のようにＣＵＳＴＵＭ、ＤＥＢＵＧ２、ＶＥＲＳＩＯＮが選択されている場合は、その設定欄に基づいて、識別子入力受付部１３は（ＲＥＬＥＡＳＥはソースコード中で宣言されている；図１１凡例参照）、コンパイラ１５に対して、”−Ｄ ＣＵＳＴＵＭ −Ｄ ＤＥＢＵＧ２ −Ｄ ＶＥＲＳＩＯＮ”のコマンドを発行する。
【００２０】
続いて、本実施の形態における詳細動作（識別子一覧の生成）について説明する。図５は、上記図４のステップ３−２における詳細動作を表したフローチャートである。初めに、ソースファイルの最初の行へ移動する（ステップ７−１）。次に、ソースファイルより一行読み出す処理が行われる（ステップ７−２）。
【００２１】
次に、読み出した行から＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出されたか否かの判断を行い（ステップ７−３）、該当する識別子が検出された場合は、後述する識別子新規登録処理を実行し（ステップ７−６）、ステップ７−９へ進む。
【００２２】
一方、ステップ７−３で＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出されなかった場合は、次に条件付コンパイルで用いるプリプロセッサ命令♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆに後続して用いられている識別子が検出されたか否かの判断を行う（ステップ７−４）。ここで、該当する識別子が検出されなかった場合は、ステップ７−９へ進む。
【００２３】
一方、ステップ７−４で♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆに後続する識別子が検出された場合は、次に、検出できた識別子と同じ名前の識別子が、識別子一覧のテーブルの識別子の列に既に存在するか否かの判断を行う（ステップ７−５）。ここで、当該識別子がテーブルに存在する場合は、既に過去に１回以上検出できたということなので、テーブルの一致した識別子の出現数に１を足し（ステップ７−７）、ステップ７−９へ進む。
【００２４】
一方、ステップ７−５で検出できた識別子と同じ名前の識別子が、テーブルに存在しない場合は、テーブルの最後に一行を追加して、ＩＤを付番し、識別子名を記述、出現数を１、設定、定義、強調表示の各要素をＯＦＦに設定し（ステップ７−８）、ステップ７−９へ進む。
【００２５】
そして、ステップ７−９で次の行に移動した時点で、ファイルの終了（ＥＯＦ）に達したか否かを確認し、終了（ＥＯＦ）ではない場合には、ステップ７−２に戻り、ソースファイルから一行読み取りフローを続行する。そして、ソースファイルの終了（ＥＯＦ）に達している場合は、識別子一覧テーブルに含まれる識別子を強調すべきか否かの強調処理要否判定（図７参照；後述する）を実行し（ステップ７−１１）、このフローを終了する。
【００２６】
図６は、図５のステップ７−６における詳細動作を表したフローチャートである。図５のステップ７−３において読み出した行から＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出された場合、検出できた識別子と同じ名前の識別子が、テーブルに存在するか否かの判断を行う（ステップ８−１）。ここで、同じ識別子がすでにテーブルに存在する場合はステップ８−３へ進む。
【００２７】
一方、同じ識別子がテーブルに存在しない場合は、テーブルの最後に一行を追加して、ＩＤを付番し、識別子名を記述、出現数を０、設定、定義、強調表示の各要素をＯＦＦに設定し（ステップ８−２）、ステップ８−３へ進む。
【００２８】
ステップ８−３では、識別子の検出箇所は＃ｄｅｆｉｎｅでの定義であるか否かの判断を行い、識別子の定義が＃ｄｅｆｉｎｅであった場合には、図３のｄｅｆｉｎｅ＿ｆｌａｇを１に設定する（ステップ８−４）。一方、識別子の定義が＃ｕｎｄｅｆであった場合には、図３のｕｎｄｅｆ＿ｆｌａｇを１に設定する（ステップ８−５）。
【００２９】
その後このフローを終了し、図６のステップ７−６に制御を返す。このようにして、ソースファイルから＃ｄｅｆｉｎｅや＃ｕｎｄｅｆが検出されると、それぞれｄｅｆｉｎｅ＿ｆｌａｇやｕｎｄｅｆ＿ｆｌａｇが更新され、最終的に当該識別子の定義状態が図３のマトリックスを用いて決定される。
【００３０】
図７は、図５のステップ７−１１における詳細動作（強調表示要否判定）を表したフローチャートである。図７を参照すると、初期化の後（ステップ９−１）、識別子一覧作成用のテーブルの識別子が順次評価される（ステップ９−２）。
【００３１】
まず、その識別子の定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）であるか否かの判断を行う（ステップ９−３）。ここで、定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）である場合は、ソース中で一つの識別子を＃ｄｅｆｉｎｅ／＃ｕｎｄｅｆの両方で定義しているのは、誤りである可能性があるため、当該識別子の強調表示をＯＮにする（ステップ９−８）。
【００３２】
一方、定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）でなかった場合は、識別子の定義がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０であるか否かの判断を行う（ステップ９−４）。識別子の定義がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０である場合は、識別子のスペルミスなどの可能性があるため、当該識別子の強調表示をＯＮにする（ステップ９−８）。
【００３３】
一方、定義状態がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０でなかった場合は、大文字・小文字の違いに過ぎない、文字構成中所定字数が共通する等、当該識別子と文字構成上の特徴が一致する類似識別子が、テーブル内に存在するか判断する類似識別子探索処理を実行する（ステップ９−５、９−６）。ここで、類似識別子が存在しない場合には、ステップ９−８の強調処理ＯＮ設定を飛ばしてステップ９−９に進む。
【００３４】
一方、類似識別子が存在する場合は、評価中（着目中）の識別子の出現数が設定値以下であるか否かを判断する（ステップ９−７）。ここで、評価中（着目中）の識別子の出現数が設定値より多い場合は、ステップ９−８の強調処理ＯＮ設定を飛ばしてステップ９−９に進む。
【００３５】
一方、類似識別子があり、評価中（着目中）の出現数が設定値（例えば３を用いる。別途ユーザが設定できるものとする）以下である場合は、その識別子がスペルミスである可能性があるため、識別子の強調表示をＯＮに設定する（ステップ９−８）。
【００３６】
そして、上記一連の評価処理が終了すると、次の識別子が存在するか否かの判断が行われ（ステップ９−９）、次の識別子がある場合には、ステップ９−１０（インクリメント処理）を経てステップ９−２に戻り、次の識別子の評価を続行する。一方、次の識別子がない場合には、この処理を終了する。
【００３７】
図９は、図８に示したサンプルソースファイルについて、上記図５のフローチャートのステップ７−１から７−１１までを実行した時点の識別子一覧作成用のテーブルを表した図である。図８を参照し、どのように判定されるかを説明すると、１行目の［＃ｄｅｆｉｎｅ ＲＥＬＥＡＳＥ］が検出され、ＩＤ番号１／ 識別子ＲＥＬＥＡＳＥ／ 出現数０／ 設定Ｏｆｆ／ 定義Ｏｎ（ｄｅｆｉｎｅ）／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００３８】
次に、２行目の［＃ｕｎｄｅｆ ＤＥＢＵＧ３］が検出され、これもテーブルにないため、ＩＤ番号２／ 識別子ＤＥＢＵＧ３／ 出現数０／ 設定Ｏｆｆ／ 定義Ｏｎ（ｕｎｄｅｆ）／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００３９】
次に、４行目の［＃ｉｆｄｅｆ ＣＵＳＴＵＭ］が検出され、これもテーブルにないため、ＩＤ番号３／ 識別子ＣＵＳＴＵＭ／ 出現数１／ 設定Ｏｆｆ／ 定義Ｏｆｆ／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００４０】
次に、８行目の［＃ｉｆｄｅｆ ＤＥＢＵＧ３］が検出されるが、これはテーブルに既に存在するため、テーブルのＩＤ番号２（ＤＥＢＵＧ３）の出現数の値が加算される（０から１に変更）。
【００４１】
次に、１１行目の［＃ｉｆｄｅｆ ＲＥＬＥＡＳＥ］が検出されるが、これもテーブルに既に存在するため、テーブルのＩＤ番号１（ＲＥＬＥＡＳＥ）の出現数の値が加算される（０から１に変更）。
【００４２】
次に、１３行目の［＃ｉｆｄｅｆ ＤＥＢＵＧ３］が検出されるが、これはテーブルに既に存在するため、テーブルのＩＤ番号２（ＤＥＢＵＧ３）の出現数の値が加算される（１から２に変更）。
【００４３】
次に、１８行目の［＃ｉｆｄｅｆ ＲＥＬＥＡＣＥ］が検出されるが、これはテーブルにないため、ＩＤ番号４／ 識別子ＲＥＬＥＡＣＥ／ 出現数１／ 設定Ｏｆｆ／ 定義Ｏｆｆ／ 強調表示Ｏｎとしたデータがテーブルに追加される。
【００４４】
以上の各判定処理をまとめたものが図９であり、この短いソースファイルでも、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥが互いに類似識別子（その判定詳細は後述する）となり、それぞれ出現数が少ないため、強調表示ＯＮ設定されることが了解される。
【００４５】
図１０は、別のソースファイルから生成された識別子一覧作成用のテーブルである。図１０を参照すると、ＩＤ番号１乃至４、７、９の識別子は強調表示がＯｆｆであり、問題点がないことが判別できる。
【００４６】
しかしながら、ソース中に６回記述されているＩＤ番号５、識別子”ＮＥＷ”は、定義フィールドは、Ｏｎ（ＤｅｆｉｎｅＵｎｄｅｆ）となっている。これは、上述したようにソース中に＃ｄｅｆｉｎｅ／ ＃ｕｎｄｅｆの両方の定義が検出されたためである。そのような不定状態は、識別子の定義ミス/スペルミスの可能性があると考えられるため、強調表示はＯＮに設定される。
【００４７】
また、ＩＤ番号６、識別子”ＯＬＤ”は、＃ｕｎｄｅｆで定義はされており、また♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆが見当たらない状態となっている（出現数が０）。この場合は、スペルミスの可能性があると考えられるため、強調表示はＯＮに設定される。
【００４８】
また、ＩＤ番号８、識別子”ＲＥＬＥＡＣＥ”は、ソース中に１回記述されているが、定義（＃ｄｅｆｉｎｅ／ ＃ｕｎｄｅｆ）は無い。この場合は、類似する（一文字相違）スペルを有するＲＥＬＥＡＳＥが存在し、かつ出現数が少ない（３回より少ない）ため、スペルミスの可能性があると判断され、強調表示はＯＮに設定される。
【００４９】
図１１は、図１０の識別子一覧作成用のテーブルを視覚的にわかりやすい態様に構成し直したものである。図１０の識別子一覧作成用のテーブルをそのまま表示してユーザに注意を喚起しても良いが、図１１の例では、出現数でソートしてあり、更に、定義と設定が設定欄にまとめて記号表示され、強調表示は行頭の「＊」でもって表されている（ＮＥＷ／ ＲＥＬＥＡＣＥ／ ＯＬＤ参照）。また、すでにソース中に明示的に宣言している識別子については、コマンドラインよりも優先的に設定されるため、凡例に示したように設定欄には状態（有効・無効）が示され、一覧表から変更できないように、適宜チェックボックスが変更不可状態にされている。
【００５０】
また、この識別子一覧は、出現数（昇順／降順）又は識別子名（辞書順）でソートできるように構成され、識別子のスペルミスや不整合をそれぞれの視点から確認できるようになっている。そして、ユーザがその識別子を使用したい場合には、設定欄のボックスをチェックして選択状態とすることができる。但し、ここでは、ＲＥＬＥＡＳＥは既にソース中で＃ｄｅｆｉｎｅで定義されているので、選択状態で変更不可能であり、ＤＥＢＵＧ３及びＯＬＤは、ソース中で＃ｕｎｄｅｆで定義されているので、未選択状態で変更不可能になっている。またＮＥＷは、ソース中で＃ｄｅｆｉｎｅかつ＃ｕｎｄｅｆで定義されているため、不定状態で変更不可能になっている。
【００５１】
図１２は、図１１の一覧により、ＲＥＬＥＡＣＥが間違っていたことに気が付き、ソースに戻り、識別子ＲＥＬＥＡＣＥをＲＥＬＥＡＳＥと訂正、識別子ＮＥＷの定義箇所を削除、識別子ＯＬＤの定義箇所を削除した後、再度出力される識別子一覧である。図１２を参照すると、エラーを暗示する行頭の「＊」は無くなっている。この状態で図１２に示されたとおり、ユーザが設定欄のチェックボックスをチェックすることにより、識別子一覧のテーブルの設定の値がＯＮになる。また、定義の値がＯｆｆ以外の識別子に関しては、設定の値は常にＯｆｆを取る。図１２の例では、ユーザが、複数の識別子”ＣＵＳＴＵＭ”、”ＤＥＢＵＧ２”、”ＶＥＲＳＩＯＮ”を使用するとして、設定欄にチェックが入れられている。従って、この状態から所定の操作を行うことで、コンパイラ１５に対して、”−Ｄ ＣＵＳＴＵＭ −Ｄ ＤＥＢＵＧ２ −Ｄ ＶＥＲＳＩＯＮ”のコマンドを発行することが可能となっている。
【００５２】
以上説明したとおり、従来の方法では、条件付きコンパイルの識別子を指定する際に、多くの識別子の設定を手動で行う必要があり、ここでスペルミスが起こる可能性があるところ、本実施の形態によれば、ユーザは、識別子一覧の強調表示に促されて間違いを容易に検出することが可能となる。また、上記の識別子一覧から定義（有効状態）したい識別子を選択することにより、識別子の定義ミスによるエラーの確率を低減することが可能である。
【００５３】
また上記した実施の形態では、強調表示をアスタリスクをもって行う例を挙げて説明したが、その他太字化、彩色変更、点滅等の強調表示を採用することができる。
【００５４】
続いて、上記第１の実施の形態における類似識別子探索をより細かく行うこととした第２の実施の形態について説明する。本実施の形態は、図７のステップ９−５の類似識別子探索処理を詳細に行う点が異なるのみであるので、既に説明した内容と重複する部分は省略し、その相違点を中心に説明する。図１３は、図７のステップ９−５の類似識別子探索処理として行われる詳細動作を表したフローチャートである。
【００５５】
図１３を参照すると、初めに、識別子一覧作成用のテーブルより、比較照合を行う識別子Ａ（ＩＤ（ｘ））と識別子Ｂ（ＩＤ（ｘ＋ｙ））が取得される（ステップ１４−１）。続いて、一文字タイプミス比較処理、識別子中のある特定の文字を一つ削除又は追加した場合残りの部分が一致するか？といった視点での判断を行う（ステップ１４−２、１４−３）。その具体的詳細は、後に図１４を用いて説明する。
【００５６】
ここで、一致（一文字多いか少ないかの相違に過ぎない）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５７】
一方、ステップ１４−３で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂがアルファベットの大文字と小文字の相違に過ぎないかどうかという視点での判定を行う（ステップ１４−４、１４−５）。ここで、例えばＤＥＢＵＧとｄｅｂｕｇ、ＲＥＬＥＡＳＥとＲｅＬＥａＳＥ等のように一致（大文字と小文字の相違に過ぎない）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５８】
一方、ステップ１４−５で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂの各文字を順番に比較し、異なっている文字数をカウントする処理を行う（ステップ１４−６）。そして、相違する文字数が所定値ｎ個以下であるか否かを判定する（ステップ１４−７）。例えば所定値ｎは、識別子の文字列の長さが３以下のときはｎ＝２、文字列の長さが４以上の時はｎ＝３とする等比較元の識別子の文字数を基準に変動させることが好ましい。例えばＤＥＢＵＧとＤＡＢＵＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥ等のように一致（相違文字がそれぞれ１文字であり、所定値ｎ以下である）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５９】
一方、ステップ１４−７で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂを比較し、ある一定数以下の文字が置き換わったに過ぎない（各文字の出現回数が略一致する）かどうかという視点で判定を行う（ステップ１４−８、１４−９）ここで、例えばＤＥＢＵＧとＤＡＢＵＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥ、ＲＥＲＥＡＳＥとＲＥＬＥＡＳＥ、のように一致（各文字の出現回数の差が所定値以下）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００６０】
図１４は、図１３のステップ１４−２における詳細動作を表したフローチャートである。図１４を参照すると、まず、文字列長の長い識別子にフラグをセットし（ステップ１５−１）、両識別子の文字列長が同じ場合を除外した上で（ステップ１５−２）、識別子Ａと識別子Ｂを先頭より順番に比較し（ステップ１５−３、１５−４）、相違が発生しても最初の相違であれば、文字列長の長い方の比較文字を進める処理を行って（ステップ１５−５）、比較を続行する（ステップ１５−６、１５−７）。最終的に、どちらか一方の識別子の特定の一文字を除外すれば、識別子Ａ、Ｂが一致する場合には「一致」、一致しない場合には「不一致」と判断する。例えば、ＤＥＢＵＧとＤＥＢＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＡＳＥは類似識別子と判断されることになる。
【００６１】
上記各判定処理において類似識別子が存在すると判定されれば、第１の実施の形態で説明した強調処理ＯＮが設定され（図７のステップ９−８）、ユーザにソースコードの確認を的確に促すことが可能となる。
【００６２】
以上、２つの識別子が類似すると判定するための方法を各種説明したが、これらは、その一例を挙げたに過ぎず、その他の処理を加えても良いし、図１３、図１４に例示された判定処理の一部を省略しても良いし、順序を変えるなどしても良い。また、上記各判定処理で用いたしきい値も適宜変更可能である。いずれにしても、手入力時に誤りやすいミスを的確に検出できるようなロジックであることが望まれる。
【００６３】
以上、本発明のいくつかの実施の形態を説明したが、その原理からも明らかなとおり、本発明の技術的範囲は、上述した実施の形態に限定されるものではなく、ソースコードから識別子一覧を生成表示しユーザに注意を喚起するとともに、該識別子一覧から識別子を設定可能とする構成という本発明の要旨を逸脱しない範囲で、各種の変形・置換をなしうることが可能であることはいうまでもない。
【００６４】
また、上記した実施の形態では、Ｃ言語を用いた例を挙げて説明したが、その原理からして明らかなとおり、Ｊａｖａ（登録商標）、Ｃ＃など、おおよそ条件付コンパイルが可能な言語であれば、特に限定するものではないことはもちろんである。
【図面の簡単な説明】
【００６５】
【図１】本発明に係るコンピュータプログラムの作成支援装置の概略構成図である。
【図２】識別子一覧のテーブル構成例を表した図である。
【図３】識別子一覧の定義状態を決定するためのマトリクスの一例である。
【図４】本発明を適用した場合のプログラム作成の基本的な流れを示したフローチャートである。
【図５】図４のステップ３−２における詳細動作を表したフローチャートである。
【図６】図５のステップ７−６における詳細動作を表したフローチャートである。
【図７】図５のステップ７−１１における詳細動作を表したフローチャートである。
【図８】本発明の実施の形態を説明するためのサンプル・ソースコードである。
【図９】図８に示したサンプルソースファイルに基づいて生成される識別子一覧作成用のテーブルを表した図である。
【図１０】別のソースファイルから生成された識別子一覧テーブルである。
【図１１】視覚的にわかりやすい態様で構成した識別子一覧の例である。
【図１２】識別子一覧の別の一例である。
【図１３】本発明の第２の実施の形態の要点を説明するためのフローチャートである。
【図１４】図１３のステップ１４−２における詳細動作を表したフローチャートである。
【図１５】従来のプログラム作成手順を示したフローチャートである。
【図１６】条件付きコンパイルのコマンド例である。
【符号の説明】
【００６６】
１１ 記憶装置
１２ 識別子一覧出力部
１３ 識別子入力受付部
１４ モニタ
１５ コンパイラ
【技術分野】
【０００１】
本発明は、プログラムソースコード（以下、ソースコードという）に含まれる条件付コンパイル用識別子の管理方法、コンピュータプログラムの作成支援装置及びプログラムに関し、特に、識別子のスペルミスを検出して条件付コンパイル（Ｃｏｎｄｉｔｉｏｎａｌ Ｃｏｍｐｉｌａｔｉｏｎ）を確実に行うことのできる識別子の管理方法、コンピュータプログラムの作成支援装置及びプログラムに関する。
【背景技術】
【０００２】
近年、アプリケーションが多機能化・多品種化しているため、それに比例して、プリプロセッサ命令（コンパイル前にソースプログラムに対して行われる前処理命令であり、文字列の置き換えやプログラムの有効／無効部分の指定が可能である）を用いた前処理が多用され、また、ソースコードも大規模かつ複雑になっている。またそのため、デバッグ作業は複雑になり時間がかかっているのが現状である。特許文献１には、ソースコード中のプリプロセッサ命令を解析し、その結果をエディタ画面に視覚的に表示する機能を備えて、プリプロセッサ命令の間違いを検出できるようにしたプログラム・エディタが紹介されている。
【０００３】
また、特許文献２、３には、ソースコード入力作業中に、入力ミスの可能性のある箇所を強調表示することのできるエディタが紹介されており、特許文献４には、プログラム中で使用されている変数の整合性チェックを行う変数データ処理装置が紹介されている。
【０００４】
図１５は、従来のプログラム作成手順を示したフローチャートである。図１５を参照すると、まずエディタなどを用いてプログラムの作成・編集を行い（ステップ１−１）、必要な箇所に条件付きコンパイルの設定が手動で行われる（ステップ１−２）。この条件付きコンパイルの設定は、機種依存性がからむ場合やデバッグ時に多用され、プログラマがソースコードや設計書から判断して、必要な箇所に条件付コンパイル用プリプロセッサとその識別子を設定することによって行われる。
【０００５】
続いて、コンパイルが行われる（ステップ１−３、１−４）。図１６は、条件付きコンパイルのコマンド例であり、この場合、ソースコード中の条件付きコンパイル用プリプロセッサ命令に後続して用いられている識別子”ＤＥＢＵＧ”、”ＴＥＳＴ”が有効化され、例えば、ソースコード中の＃ｉｆｄｅｆ ＤＥＢＵＧの行から、＃ｅｎｄｉｆまでの部分がコンパイルの対象となる。このコンパイルの過程で、エラーのチェックが行われるが、ここで文法上のエラーがある場合は、コンパイラがエラーを表示する（プリプロセッサ命令自体の入力ミス等の文法エラーも含む）。そして、エラーと表示された場合は、再びプログラムの修正に移る（ステップ１−１）。一方、エラーが無い場合にはデバッグ作業に移る。
【０００６】
次のデバッグ作業では、さまざまな評価を行い、プログラムが仕様書通りに動いているか評価を行う（ステップ１−５、１−６）。ここで、誤作動に気が付けば、様々なツールを使用したり、実際にソースを読むことにより、プログラムの論理的なエラーなどを発見して、ソースコードの修正に移る（ステップ１−１）。エラーが発見されなかった場合は、プログラムの作成は終了になる。
【０００７】
【特許文献１】特開２０００−１４８５０８号公報
【特許文献２】特開平５−３４１９７６号公報
【特許文献３】特開平１１−７３３０５号公報
【特許文献４】特開平７−７８０７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
条件付コンパイルで用いるプリプロセッサ命令に後続する「識別子」として、任意の文字を定義可能であって大変便利であるが、その反面、プリプロセッサ命令を含む行は文法的に独立したものと取扱われるため、以下のような負担が生じていたといえる。第１の問題点は、コンパイル時のエラーチェックでは、たとえ入力ミスであってもそのような識別子が設定されているものと判断され検出できないことにある。例えば、図１６のように、コンパイルコマンドで「ＤＥＢＵＧ」と指定したのに対し、ソースコードでは識別子「ＤＥＢＡＧ」（入力ミス）が定義されていたとしても、コンパイラは誤りとせず識別子「ＤＥＢＵＧ」の条件付きコンパイルを行う。このように、識別子の入力ミスは、デバッグ作業でしか発見することができず、条件付きコンパイルの識別子のスペルミスの不具合が発生すると、デバッグ作業を強いられることになり、大規模かつ複雑なソースコードではかなりの負担となっている。
【０００９】
第２の問題点は、条件付きコンパイルの識別子を指定する際に、多くの識別子の設定を手動で行う必要があるため、同一の識別子が指定されるべきところ、別の識別子が設定されるなど、見落としや指定間違いが発生する危険性が常にあったことにある。大規模なソースコードは、複数の人間がプログラミングしており、更には、一つのソースコードで多くの品種・バージョンに対応するため、複雑に条件付きコンパイルのプリプロセッサ命令が指定されている場合もある。また、ソースコードが大規模で複雑であれば、条件付きコンパイルが正しく設定できているかどうかを検証することも困難となり、プログラム開発作業の効率化を阻害する要因ともなっている。
【００１０】
この点、特許文献１は、プリプロセッサ命令の解釈結果を編集画面上に視覚的に表示するものであるから、デバッグ作業の軽減にはなったとしても、大規模かつ複雑なソースコードでは上記各問題点を根本的に解決するものとはならない。また、特許文献２、３の技術をもってしても、条件付コンパイル用の識別子の場合、何をもって入力ミスと判定するかどうかも一義的でなく適用が困難である。また、特許文献４に記載の技術も、インタプリタ系言語に特有の変数の整合性をチェックするためのものであり、この種の問題は、コンパイラ系言語では、コンパイル時に検出することが可能となっているものである。
【課題を解決するための手段】
【００１１】
本発明の第１の視点によれば、少なくともコンパイルする前の段階で、コンピュータが、プログラムソースコードを走査して、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示し、ユーザに注意を喚起することのできる条件付コンパイル用の識別子の管理方法が提供される。
【００１２】
本発明の第２の視点によれば、上記した条件付コンパイル用の識別子の管理方法において、少なくともコンパイルコマンド入力時に、前記コンピュータが、前記識別子一覧からユーザによって選択された識別子を、条件付コンパイル用の識別子として設定すること、を特徴とする条件付コンパイル用の識別子の管理方法が提供される。
【００１３】
本発明の第３の視点によれば、上記したソースコード中の識別子の管理方法を実施するためのコンピュータプログラムの作成支援装置、及び、コンピュータに上記ソースコード中の識別子の管理方法を実施するためのコンピュータ・プログラム（チェッカ・プログラム、プログラム作成支援プログラム）が提供される。
【発明の効果】
【００１４】
本発明によれば、少なくとも出現回数と定義状態を併記した識別子一覧を参照して、識別子のスペルミスや不整合を発見することが可能となる。
【発明を実施するための最良の形態】
【００１５】
続いて、本発明を統合開発環境（Ｉｎｔｅｇｒａｔｅｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｎｖｉｒｏｎｍｅｎｔ）に適用した本発明の好適な実施の形態について、図面を参照して詳細に説明する。図１は、本発明に係るコンピュータプログラムの作成支援装置の概略構成図である。図１を参照すると、コンピュータプログラムの作成支援装置には、ソースコードやオブジェクトコードを記憶保持する記憶装置１１、後述する動作を行う識別子一覧出力部１２及び識別子入力受付部１３、コンパイラ１５（これらは、コンピュータのハードウェア資源利用するコンピュータプログラムで構成され、前２者については後に詳述する。）、識別子一覧を表示するためのモニタ１４とのほか、図示しないエディタ、デバッガ等プログラミングに必要なツールが統合して扱えるような環境が整えられている。
【００１６】
図２は、識別子一覧出力部１２で管理される識別子一覧作成用のテーブル構成を表した図である。図２を参照すると、ＩＤ（通し番号）、識別子名（文字列）、出現数（ソースファイル中の出現回数）、設定（使用＝ＯＮ／不使用＝ＯＦＦ）、定義、強調表示（ＯＮ／ＯＦＦ）といったフィールドが設けられ、ＩＤで識別される識別子の情報を格納可能となっている。また、定義フィールドには、ソースファイル中にその識別子を定義している部分がないことを示す「ＯＦＦ」、ソースファイル中にその識別子をプリプロセッサ命令＃ｄｅｆｉｎｅで定義していることを示す「ＯＮ（Ｄｅｆｉｎｅ）」、ソースファイル中にその識別子をプリプロセッサ命令＃ｕｎｄｅｆで定義していることを示す「ＯＮ（Ｕｎｄｅｆ）」、ソースファイル中にその識別子をプリプロセッサ命令＃ｄｅｆｉｎｅ及び＃ｕｎｄｅｆで定義していることを示す「ＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）」が記述される。識別子一覧出力部１２は、このテーブルの適宜項目を選択・表示してユーザに提供する。
【００１７】
図３は、上記した識別子一覧のテーブル構成中の定義欄の４つの状態を求めるためのマトリクスである。図３を参照すると、ソースファイル中にその識別子が＃ｄｅｆｉｎｅで定義されている場合に、ｄｅｆｉｎｅ＿ｆｌａｇが１となり、＃ｕｎｄｅｆで定義されている場合に、ｕｎｄｅｆ＿ｆｌａｇが１となり、これらの組合せによって、上記ＯＦＦ〜ＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）までのいずれかの状態を求めることが可能となっている。
【００１８】
図４は、本発明を適用した場合のプログラム作成の大まかな流れを示したフローチャートである。図４を参照すると、プログラムの作成・修正が終了したら（ステップ３−１）、識別子一覧出力部１２がソースコードから条件付きコンパイルの識別子一覧を作成する処理を実行する（ステップ３−２）。
【００１９】
次いで、モニタ１４に出力された識別子一覧表（図１１参照）より、適宜強調表示された識別子を確認して識別子にスペルミスや不整合があるかを確認し（ステップ３−３、３−４）、スペルミスが存在する場合は、再びプログラムの作成・修正に戻る（ステップ３−１）。一方、識別子にスペルミスがない場合には、識別子一覧表から、有効にする識別子を選択する（ステップ３−５）。例えば、図１２のようにＣＵＳＴＵＭ、ＤＥＢＵＧ２、ＶＥＲＳＩＯＮが選択されている場合は、その設定欄に基づいて、識別子入力受付部１３は（ＲＥＬＥＡＳＥはソースコード中で宣言されている；図１１凡例参照）、コンパイラ１５に対して、”−Ｄ ＣＵＳＴＵＭ −Ｄ ＤＥＢＵＧ２ −Ｄ ＶＥＲＳＩＯＮ”のコマンドを発行する。
【００２０】
続いて、本実施の形態における詳細動作（識別子一覧の生成）について説明する。図５は、上記図４のステップ３−２における詳細動作を表したフローチャートである。初めに、ソースファイルの最初の行へ移動する（ステップ７−１）。次に、ソースファイルより一行読み出す処理が行われる（ステップ７−２）。
【００２１】
次に、読み出した行から＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出されたか否かの判断を行い（ステップ７−３）、該当する識別子が検出された場合は、後述する識別子新規登録処理を実行し（ステップ７−６）、ステップ７−９へ進む。
【００２２】
一方、ステップ７−３で＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出されなかった場合は、次に条件付コンパイルで用いるプリプロセッサ命令♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆに後続して用いられている識別子が検出されたか否かの判断を行う（ステップ７−４）。ここで、該当する識別子が検出されなかった場合は、ステップ７−９へ進む。
【００２３】
一方、ステップ７−４で♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆに後続する識別子が検出された場合は、次に、検出できた識別子と同じ名前の識別子が、識別子一覧のテーブルの識別子の列に既に存在するか否かの判断を行う（ステップ７−５）。ここで、当該識別子がテーブルに存在する場合は、既に過去に１回以上検出できたということなので、テーブルの一致した識別子の出現数に１を足し（ステップ７−７）、ステップ７−９へ進む。
【００２４】
一方、ステップ７−５で検出できた識別子と同じ名前の識別子が、テーブルに存在しない場合は、テーブルの最後に一行を追加して、ＩＤを付番し、識別子名を記述、出現数を１、設定、定義、強調表示の各要素をＯＦＦに設定し（ステップ７−８）、ステップ７−９へ進む。
【００２５】
そして、ステップ７−９で次の行に移動した時点で、ファイルの終了（ＥＯＦ）に達したか否かを確認し、終了（ＥＯＦ）ではない場合には、ステップ７−２に戻り、ソースファイルから一行読み取りフローを続行する。そして、ソースファイルの終了（ＥＯＦ）に達している場合は、識別子一覧テーブルに含まれる識別子を強調すべきか否かの強調処理要否判定（図７参照；後述する）を実行し（ステップ７−１１）、このフローを終了する。
【００２６】
図６は、図５のステップ７−６における詳細動作を表したフローチャートである。図５のステップ７−３において読み出した行から＃ｄｅｆｉｎｅ又は＃ｕｎｄｅｆに後続する識別子が検出された場合、検出できた識別子と同じ名前の識別子が、テーブルに存在するか否かの判断を行う（ステップ８−１）。ここで、同じ識別子がすでにテーブルに存在する場合はステップ８−３へ進む。
【００２７】
一方、同じ識別子がテーブルに存在しない場合は、テーブルの最後に一行を追加して、ＩＤを付番し、識別子名を記述、出現数を０、設定、定義、強調表示の各要素をＯＦＦに設定し（ステップ８−２）、ステップ８−３へ進む。
【００２８】
ステップ８−３では、識別子の検出箇所は＃ｄｅｆｉｎｅでの定義であるか否かの判断を行い、識別子の定義が＃ｄｅｆｉｎｅであった場合には、図３のｄｅｆｉｎｅ＿ｆｌａｇを１に設定する（ステップ８−４）。一方、識別子の定義が＃ｕｎｄｅｆであった場合には、図３のｕｎｄｅｆ＿ｆｌａｇを１に設定する（ステップ８−５）。
【００２９】
その後このフローを終了し、図６のステップ７−６に制御を返す。このようにして、ソースファイルから＃ｄｅｆｉｎｅや＃ｕｎｄｅｆが検出されると、それぞれｄｅｆｉｎｅ＿ｆｌａｇやｕｎｄｅｆ＿ｆｌａｇが更新され、最終的に当該識別子の定義状態が図３のマトリックスを用いて決定される。
【００３０】
図７は、図５のステップ７−１１における詳細動作（強調表示要否判定）を表したフローチャートである。図７を参照すると、初期化の後（ステップ９−１）、識別子一覧作成用のテーブルの識別子が順次評価される（ステップ９−２）。
【００３１】
まず、その識別子の定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）であるか否かの判断を行う（ステップ９−３）。ここで、定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）である場合は、ソース中で一つの識別子を＃ｄｅｆｉｎｅ／＃ｕｎｄｅｆの両方で定義しているのは、誤りである可能性があるため、当該識別子の強調表示をＯＮにする（ステップ９−８）。
【００３２】
一方、定義状態がＯＮ（ＤｅｆｉｎｅＵｎｄｅｆ）でなかった場合は、識別子の定義がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０であるか否かの判断を行う（ステップ９−４）。識別子の定義がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０である場合は、識別子のスペルミスなどの可能性があるため、当該識別子の強調表示をＯＮにする（ステップ９−８）。
【００３３】
一方、定義状態がＯＮ（ｄｅｆｉｎｅ）又はＯＮ（ｕｎｄｅｆ）であって、かつ、出現数が０でなかった場合は、大文字・小文字の違いに過ぎない、文字構成中所定字数が共通する等、当該識別子と文字構成上の特徴が一致する類似識別子が、テーブル内に存在するか判断する類似識別子探索処理を実行する（ステップ９−５、９−６）。ここで、類似識別子が存在しない場合には、ステップ９−８の強調処理ＯＮ設定を飛ばしてステップ９−９に進む。
【００３４】
一方、類似識別子が存在する場合は、評価中（着目中）の識別子の出現数が設定値以下であるか否かを判断する（ステップ９−７）。ここで、評価中（着目中）の識別子の出現数が設定値より多い場合は、ステップ９−８の強調処理ＯＮ設定を飛ばしてステップ９−９に進む。
【００３５】
一方、類似識別子があり、評価中（着目中）の出現数が設定値（例えば３を用いる。別途ユーザが設定できるものとする）以下である場合は、その識別子がスペルミスである可能性があるため、識別子の強調表示をＯＮに設定する（ステップ９−８）。
【００３６】
そして、上記一連の評価処理が終了すると、次の識別子が存在するか否かの判断が行われ（ステップ９−９）、次の識別子がある場合には、ステップ９−１０（インクリメント処理）を経てステップ９−２に戻り、次の識別子の評価を続行する。一方、次の識別子がない場合には、この処理を終了する。
【００３７】
図９は、図８に示したサンプルソースファイルについて、上記図５のフローチャートのステップ７−１から７−１１までを実行した時点の識別子一覧作成用のテーブルを表した図である。図８を参照し、どのように判定されるかを説明すると、１行目の［＃ｄｅｆｉｎｅ ＲＥＬＥＡＳＥ］が検出され、ＩＤ番号１／ 識別子ＲＥＬＥＡＳＥ／ 出現数０／ 設定Ｏｆｆ／ 定義Ｏｎ（ｄｅｆｉｎｅ）／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００３８】
次に、２行目の［＃ｕｎｄｅｆ ＤＥＢＵＧ３］が検出され、これもテーブルにないため、ＩＤ番号２／ 識別子ＤＥＢＵＧ３／ 出現数０／ 設定Ｏｆｆ／ 定義Ｏｎ（ｕｎｄｅｆ）／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００３９】
次に、４行目の［＃ｉｆｄｅｆ ＣＵＳＴＵＭ］が検出され、これもテーブルにないため、ＩＤ番号３／ 識別子ＣＵＳＴＵＭ／ 出現数１／ 設定Ｏｆｆ／ 定義Ｏｆｆ／ 強調表示Ｏｆｆとしたデータがテーブルに追加される。
【００４０】
次に、８行目の［＃ｉｆｄｅｆ ＤＥＢＵＧ３］が検出されるが、これはテーブルに既に存在するため、テーブルのＩＤ番号２（ＤＥＢＵＧ３）の出現数の値が加算される（０から１に変更）。
【００４１】
次に、１１行目の［＃ｉｆｄｅｆ ＲＥＬＥＡＳＥ］が検出されるが、これもテーブルに既に存在するため、テーブルのＩＤ番号１（ＲＥＬＥＡＳＥ）の出現数の値が加算される（０から１に変更）。
【００４２】
次に、１３行目の［＃ｉｆｄｅｆ ＤＥＢＵＧ３］が検出されるが、これはテーブルに既に存在するため、テーブルのＩＤ番号２（ＤＥＢＵＧ３）の出現数の値が加算される（１から２に変更）。
【００４３】
次に、１８行目の［＃ｉｆｄｅｆ ＲＥＬＥＡＣＥ］が検出されるが、これはテーブルにないため、ＩＤ番号４／ 識別子ＲＥＬＥＡＣＥ／ 出現数１／ 設定Ｏｆｆ／ 定義Ｏｆｆ／ 強調表示Ｏｎとしたデータがテーブルに追加される。
【００４４】
以上の各判定処理をまとめたものが図９であり、この短いソースファイルでも、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥが互いに類似識別子（その判定詳細は後述する）となり、それぞれ出現数が少ないため、強調表示ＯＮ設定されることが了解される。
【００４５】
図１０は、別のソースファイルから生成された識別子一覧作成用のテーブルである。図１０を参照すると、ＩＤ番号１乃至４、７、９の識別子は強調表示がＯｆｆであり、問題点がないことが判別できる。
【００４６】
しかしながら、ソース中に６回記述されているＩＤ番号５、識別子”ＮＥＷ”は、定義フィールドは、Ｏｎ（ＤｅｆｉｎｅＵｎｄｅｆ）となっている。これは、上述したようにソース中に＃ｄｅｆｉｎｅ／ ＃ｕｎｄｅｆの両方の定義が検出されたためである。そのような不定状態は、識別子の定義ミス/スペルミスの可能性があると考えられるため、強調表示はＯＮに設定される。
【００４７】
また、ＩＤ番号６、識別子”ＯＬＤ”は、＃ｕｎｄｅｆで定義はされており、また♯ｉｆｄｅｆ、♯ｉｆ ｄｅｆｉｎｅ又は＃ｅｌｉｆが見当たらない状態となっている（出現数が０）。この場合は、スペルミスの可能性があると考えられるため、強調表示はＯＮに設定される。
【００４８】
また、ＩＤ番号８、識別子”ＲＥＬＥＡＣＥ”は、ソース中に１回記述されているが、定義（＃ｄｅｆｉｎｅ／ ＃ｕｎｄｅｆ）は無い。この場合は、類似する（一文字相違）スペルを有するＲＥＬＥＡＳＥが存在し、かつ出現数が少ない（３回より少ない）ため、スペルミスの可能性があると判断され、強調表示はＯＮに設定される。
【００４９】
図１１は、図１０の識別子一覧作成用のテーブルを視覚的にわかりやすい態様に構成し直したものである。図１０の識別子一覧作成用のテーブルをそのまま表示してユーザに注意を喚起しても良いが、図１１の例では、出現数でソートしてあり、更に、定義と設定が設定欄にまとめて記号表示され、強調表示は行頭の「＊」でもって表されている（ＮＥＷ／ ＲＥＬＥＡＣＥ／ ＯＬＤ参照）。また、すでにソース中に明示的に宣言している識別子については、コマンドラインよりも優先的に設定されるため、凡例に示したように設定欄には状態（有効・無効）が示され、一覧表から変更できないように、適宜チェックボックスが変更不可状態にされている。
【００５０】
また、この識別子一覧は、出現数（昇順／降順）又は識別子名（辞書順）でソートできるように構成され、識別子のスペルミスや不整合をそれぞれの視点から確認できるようになっている。そして、ユーザがその識別子を使用したい場合には、設定欄のボックスをチェックして選択状態とすることができる。但し、ここでは、ＲＥＬＥＡＳＥは既にソース中で＃ｄｅｆｉｎｅで定義されているので、選択状態で変更不可能であり、ＤＥＢＵＧ３及びＯＬＤは、ソース中で＃ｕｎｄｅｆで定義されているので、未選択状態で変更不可能になっている。またＮＥＷは、ソース中で＃ｄｅｆｉｎｅかつ＃ｕｎｄｅｆで定義されているため、不定状態で変更不可能になっている。
【００５１】
図１２は、図１１の一覧により、ＲＥＬＥＡＣＥが間違っていたことに気が付き、ソースに戻り、識別子ＲＥＬＥＡＣＥをＲＥＬＥＡＳＥと訂正、識別子ＮＥＷの定義箇所を削除、識別子ＯＬＤの定義箇所を削除した後、再度出力される識別子一覧である。図１２を参照すると、エラーを暗示する行頭の「＊」は無くなっている。この状態で図１２に示されたとおり、ユーザが設定欄のチェックボックスをチェックすることにより、識別子一覧のテーブルの設定の値がＯＮになる。また、定義の値がＯｆｆ以外の識別子に関しては、設定の値は常にＯｆｆを取る。図１２の例では、ユーザが、複数の識別子”ＣＵＳＴＵＭ”、”ＤＥＢＵＧ２”、”ＶＥＲＳＩＯＮ”を使用するとして、設定欄にチェックが入れられている。従って、この状態から所定の操作を行うことで、コンパイラ１５に対して、”−Ｄ ＣＵＳＴＵＭ −Ｄ ＤＥＢＵＧ２ −Ｄ ＶＥＲＳＩＯＮ”のコマンドを発行することが可能となっている。
【００５２】
以上説明したとおり、従来の方法では、条件付きコンパイルの識別子を指定する際に、多くの識別子の設定を手動で行う必要があり、ここでスペルミスが起こる可能性があるところ、本実施の形態によれば、ユーザは、識別子一覧の強調表示に促されて間違いを容易に検出することが可能となる。また、上記の識別子一覧から定義（有効状態）したい識別子を選択することにより、識別子の定義ミスによるエラーの確率を低減することが可能である。
【００５３】
また上記した実施の形態では、強調表示をアスタリスクをもって行う例を挙げて説明したが、その他太字化、彩色変更、点滅等の強調表示を採用することができる。
【００５４】
続いて、上記第１の実施の形態における類似識別子探索をより細かく行うこととした第２の実施の形態について説明する。本実施の形態は、図７のステップ９−５の類似識別子探索処理を詳細に行う点が異なるのみであるので、既に説明した内容と重複する部分は省略し、その相違点を中心に説明する。図１３は、図７のステップ９−５の類似識別子探索処理として行われる詳細動作を表したフローチャートである。
【００５５】
図１３を参照すると、初めに、識別子一覧作成用のテーブルより、比較照合を行う識別子Ａ（ＩＤ（ｘ））と識別子Ｂ（ＩＤ（ｘ＋ｙ））が取得される（ステップ１４−１）。続いて、一文字タイプミス比較処理、識別子中のある特定の文字を一つ削除又は追加した場合残りの部分が一致するか？といった視点での判断を行う（ステップ１４−２、１４−３）。その具体的詳細は、後に図１４を用いて説明する。
【００５６】
ここで、一致（一文字多いか少ないかの相違に過ぎない）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５７】
一方、ステップ１４−３で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂがアルファベットの大文字と小文字の相違に過ぎないかどうかという視点での判定を行う（ステップ１４−４、１４−５）。ここで、例えばＤＥＢＵＧとｄｅｂｕｇ、ＲＥＬＥＡＳＥとＲｅＬＥａＳＥ等のように一致（大文字と小文字の相違に過ぎない）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５８】
一方、ステップ１４−５で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂの各文字を順番に比較し、異なっている文字数をカウントする処理を行う（ステップ１４−６）。そして、相違する文字数が所定値ｎ個以下であるか否かを判定する（ステップ１４−７）。例えば所定値ｎは、識別子の文字列の長さが３以下のときはｎ＝２、文字列の長さが４以上の時はｎ＝３とする等比較元の識別子の文字数を基準に変動させることが好ましい。例えばＤＥＢＵＧとＤＡＢＵＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥ等のように一致（相違文字がそれぞれ１文字であり、所定値ｎ以下である）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００５９】
一方、ステップ１４−７で一致しないと判定した場合、続いて、識別子Ａと識別子Ｂを比較し、ある一定数以下の文字が置き換わったに過ぎない（各文字の出現回数が略一致する）かどうかという視点で判定を行う（ステップ１４−８、１４−９）ここで、例えばＤＥＢＵＧとＤＡＢＵＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＣＥ、ＲＥＲＥＡＳＥとＲＥＬＥＡＳＥ、のように一致（各文字の出現回数の差が所定値以下）と判定した場合は、ステップ１４−１０に進み、類似識別子と判定される。
【００６０】
図１４は、図１３のステップ１４−２における詳細動作を表したフローチャートである。図１４を参照すると、まず、文字列長の長い識別子にフラグをセットし（ステップ１５−１）、両識別子の文字列長が同じ場合を除外した上で（ステップ１５−２）、識別子Ａと識別子Ｂを先頭より順番に比較し（ステップ１５−３、１５−４）、相違が発生しても最初の相違であれば、文字列長の長い方の比較文字を進める処理を行って（ステップ１５−５）、比較を続行する（ステップ１５−６、１５−７）。最終的に、どちらか一方の識別子の特定の一文字を除外すれば、識別子Ａ、Ｂが一致する場合には「一致」、一致しない場合には「不一致」と判断する。例えば、ＤＥＢＵＧとＤＥＢＧ、ＲＥＬＥＡＳＥとＲＥＬＥＡＡＳＥは類似識別子と判断されることになる。
【００６１】
上記各判定処理において類似識別子が存在すると判定されれば、第１の実施の形態で説明した強調処理ＯＮが設定され（図７のステップ９−８）、ユーザにソースコードの確認を的確に促すことが可能となる。
【００６２】
以上、２つの識別子が類似すると判定するための方法を各種説明したが、これらは、その一例を挙げたに過ぎず、その他の処理を加えても良いし、図１３、図１４に例示された判定処理の一部を省略しても良いし、順序を変えるなどしても良い。また、上記各判定処理で用いたしきい値も適宜変更可能である。いずれにしても、手入力時に誤りやすいミスを的確に検出できるようなロジックであることが望まれる。
【００６３】
以上、本発明のいくつかの実施の形態を説明したが、その原理からも明らかなとおり、本発明の技術的範囲は、上述した実施の形態に限定されるものではなく、ソースコードから識別子一覧を生成表示しユーザに注意を喚起するとともに、該識別子一覧から識別子を設定可能とする構成という本発明の要旨を逸脱しない範囲で、各種の変形・置換をなしうることが可能であることはいうまでもない。
【００６４】
また、上記した実施の形態では、Ｃ言語を用いた例を挙げて説明したが、その原理からして明らかなとおり、Ｊａｖａ（登録商標）、Ｃ＃など、おおよそ条件付コンパイルが可能な言語であれば、特に限定するものではないことはもちろんである。
【図面の簡単な説明】
【００６５】
【図１】本発明に係るコンピュータプログラムの作成支援装置の概略構成図である。
【図２】識別子一覧のテーブル構成例を表した図である。
【図３】識別子一覧の定義状態を決定するためのマトリクスの一例である。
【図４】本発明を適用した場合のプログラム作成の基本的な流れを示したフローチャートである。
【図５】図４のステップ３−２における詳細動作を表したフローチャートである。
【図６】図５のステップ７−６における詳細動作を表したフローチャートである。
【図７】図５のステップ７−１１における詳細動作を表したフローチャートである。
【図８】本発明の実施の形態を説明するためのサンプル・ソースコードである。
【図９】図８に示したサンプルソースファイルに基づいて生成される識別子一覧作成用のテーブルを表した図である。
【図１０】別のソースファイルから生成された識別子一覧テーブルである。
【図１１】視覚的にわかりやすい態様で構成した識別子一覧の例である。
【図１２】識別子一覧の別の一例である。
【図１３】本発明の第２の実施の形態の要点を説明するためのフローチャートである。
【図１４】図１３のステップ１４−２における詳細動作を表したフローチャートである。
【図１５】従来のプログラム作成手順を示したフローチャートである。
【図１６】条件付きコンパイルのコマンド例である。
【符号の説明】
【００６６】
１１ 記憶装置
１２ 識別子一覧出力部
１３ 識別子入力受付部
１４ モニタ
１５ コンパイラ
【特許請求の範囲】
【請求項１】
コンピュータによるプログラムソースコードに含まれる条件付コンパイル用の識別子の管理方法であって、
前記コンピュータが、プログラムソースコードを走査し、
少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する工程を、含むこと、
を特徴とする条件付コンパイル用の識別子の管理方法。
【請求項２】
請求項１に記載の条件付コンパイル用の識別子の管理方法であって、更に、
少なくともコンパイルコマンド入力時に、前記コンピュータが、前記識別子一覧からユーザによって選択された識別子を、条件付コンパイル用の識別子として設定する工程を含むこと、
を特徴とする条件付コンパイル用の識別子の管理方法。
【請求項３】
コンピュータプログラムの作成支援装置であって、
プログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する識別子一覧出力部を備えたこと、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項４】
請求項３に記載のコンピュータプログラムの作成支援装置であって、更に、
少なくともコンパイルコマンド入力時に、前記識別子一覧から任意の識別子を選択することによって、条件付コンパイル用の識別子の設定を受け付ける識別子入力受付部を備えたこと、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項５】
請求項３又は４に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧は、識別子に使用された文字順でソートされていること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項６】
請求項３乃至５いずれか一に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧は、識別子の出現回数でソートされていること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項７】
請求項３又は６いずれか一に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧の識別子同士を照合し、着目する識別子と文字構成上の特徴が一致する類似識別子が存在し、かつ、着目する識別子の出現回数が所定値より少ない場合は、前記識別子一覧の該識別子の部分を強調表示すること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項８】
請求項３又は７いずれか一に記載のコンピュータプログラムの作成支援装置において、
着目する識別子の文字列から少なくとも１文字を削除して並べた文字列と、一致する識別子が検出された場合は、前記文字構成上の特徴が一致する類似識別子と判定すること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項９】
コンピュータプログラムの作成支援のためのチェッカプログラムであって、
チェック対象のプログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する処理をコンピュータに実行させるチェッカプログラム。
【請求項１０】
請求項９に記載のチェッカプログラムにおいて、更に、
識別子に使用された文字順で各識別子をソートした識別子一覧を生成すること、
を特徴とするチェッカプログラム。
【請求項１１】
請求項９又は１０に記載のチェッカプログラムにおいて、
識別子の出現回数で各識別子をソートした識別子一覧を生成すること、
を特徴とするチェッカプログラム。
【請求項１２】
請求項９乃至１１いずれか一に記載のチェッカプログラムにおいて、更に、
前記識別子一覧の識別子同士を照合する処理と、
着目する識別子と文字構成上の特徴が一致する類似識別子が存在し、かつ、着目する識別子の出現回数が所定値より少ない場合は、前記識別子一覧の該識別子の部分を強調表示する処理と、を前記コンピュータに実行させるチェッカプログラム。
【請求項１３】
請求項９乃至１２いずれか一に記載のチェッカプログラムにおいて、更に、
着目する識別子の文字列から少なくとも１文字を削除して並べた文字列と、一致する識別子が検出された場合は、前記文字構成上の特徴が一致する類似識別子と判定すること、
を特徴とするチェッカプログラム。
【請求項１４】
請求項９乃至１３いずれか一に記載のチェッカプログラムを含み、
前記識別子一覧から任意の識別子を選択することで識別子の設定を受け付ける処理を、前記コンピュータに実行させるコンピュータプログラムの作成支援プログラム。
【請求項１】
コンピュータによるプログラムソースコードに含まれる条件付コンパイル用の識別子の管理方法であって、
前記コンピュータが、プログラムソースコードを走査し、
少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する工程を、含むこと、
を特徴とする条件付コンパイル用の識別子の管理方法。
【請求項２】
請求項１に記載の条件付コンパイル用の識別子の管理方法であって、更に、
少なくともコンパイルコマンド入力時に、前記コンピュータが、前記識別子一覧からユーザによって選択された識別子を、条件付コンパイル用の識別子として設定する工程を含むこと、
を特徴とする条件付コンパイル用の識別子の管理方法。
【請求項３】
コンピュータプログラムの作成支援装置であって、
プログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する識別子一覧出力部を備えたこと、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項４】
請求項３に記載のコンピュータプログラムの作成支援装置であって、更に、
少なくともコンパイルコマンド入力時に、前記識別子一覧から任意の識別子を選択することによって、条件付コンパイル用の識別子の設定を受け付ける識別子入力受付部を備えたこと、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項５】
請求項３又は４に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧は、識別子に使用された文字順でソートされていること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項６】
請求項３乃至５いずれか一に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧は、識別子の出現回数でソートされていること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項７】
請求項３又は６いずれか一に記載のコンピュータプログラムの作成支援装置において、
前記識別子一覧の識別子同士を照合し、着目する識別子と文字構成上の特徴が一致する類似識別子が存在し、かつ、着目する識別子の出現回数が所定値より少ない場合は、前記識別子一覧の該識別子の部分を強調表示すること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項８】
請求項３又は７いずれか一に記載のコンピュータプログラムの作成支援装置において、
着目する識別子の文字列から少なくとも１文字を削除して並べた文字列と、一致する識別子が検出された場合は、前記文字構成上の特徴が一致する類似識別子と判定すること、
を特徴とするコンピュータプログラムの作成支援装置。
【請求項９】
コンピュータプログラムの作成支援のためのチェッカプログラムであって、
チェック対象のプログラムソースコードを走査し、少なくとも、条件付コンパイル用のプリプロセッサ命令に後続して用いられている識別子とその出現回数と、識別子が定義されているか否かを示した定義状態と、を併記した識別子一覧を生成表示する処理をコンピュータに実行させるチェッカプログラム。
【請求項１０】
請求項９に記載のチェッカプログラムにおいて、更に、
識別子に使用された文字順で各識別子をソートした識別子一覧を生成すること、
を特徴とするチェッカプログラム。
【請求項１１】
請求項９又は１０に記載のチェッカプログラムにおいて、
識別子の出現回数で各識別子をソートした識別子一覧を生成すること、
を特徴とするチェッカプログラム。
【請求項１２】
請求項９乃至１１いずれか一に記載のチェッカプログラムにおいて、更に、
前記識別子一覧の識別子同士を照合する処理と、
着目する識別子と文字構成上の特徴が一致する類似識別子が存在し、かつ、着目する識別子の出現回数が所定値より少ない場合は、前記識別子一覧の該識別子の部分を強調表示する処理と、を前記コンピュータに実行させるチェッカプログラム。
【請求項１３】
請求項９乃至１２いずれか一に記載のチェッカプログラムにおいて、更に、
着目する識別子の文字列から少なくとも１文字を削除して並べた文字列と、一致する識別子が検出された場合は、前記文字構成上の特徴が一致する類似識別子と判定すること、
を特徴とするチェッカプログラム。
【請求項１４】
請求項９乃至１３いずれか一に記載のチェッカプログラムを含み、
前記識別子一覧から任意の識別子を選択することで識別子の設定を受け付ける処理を、前記コンピュータに実行させるコンピュータプログラムの作成支援プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００６−２１５８９６（Ｐ２００６−２１５８９６Ａ）
【公開日】平成１８年８月１７日（２００６．８．１７）
【国際特許分類】
【出願番号】特願２００５−２９３７６（Ｐ２００５−２９３７６）
【出願日】平成１７年２月４日（２００５．２．４）
【出願人】（０００２３２０３６）ＮＥＣマイクロシステム株式会社 (72)
【Ｆターム（参考）】
【公開日】平成１８年８月１７日（２００６．８．１７）
【国際特許分類】
【出願日】平成１７年２月４日（２００５．２．４）
【出願人】（０００２３２０３６）ＮＥＣマイクロシステム株式会社 (72)
【Ｆターム（参考）】
[ Back to top ]