メトリックスに関するFAQ
質問1. QACのメトリックサマリについて教えてください。

QA Cのメトリックサマリについての推奨値の情報を教えていただけないでしょうか。
戻る
回答1.

代表的なメトリックスの標準値を示します。
Version: 4.0.3J, 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

QA Cの出力にあるキビアット図の中で境界値が決められている一部メトリックスを抜粋し、その標準値が何から算出されているかについて説明します。

元々メトリックスの研究と言語の話とは別物で、メトリックス値の算出式は表示しても、その値に対する合格点等、データを出して説明している参考文献も少ないため、文献からメトリックの基準値を得ることは困難です。

QA Cのメトリックスの基準値は、QA Cの製造元である PRL社が関わりをもったソースコードと算出式から得られた値の統計です。

最小値(奨励値)に関する算出基準はわかりませんが、最大値については若干参考資料に説明がありますので以下に示します。

識別子 メトリックス名 最小値 最大値
STCYC 経路複雑度 2 10
STPTH 静的経路数見積 4 200
STMIF 制御構造のネスティング 1 5
STSUB 関数呼び出しの数 1 10
STLIN 保守可能なコード行数 1 200
 
STCYC 判定数プラス1で算出される値。
McCabe(1976)によると制約をもったソフトウェアは 最大値を 10と提案しています。 場合によっては、承認(署名)付きで 20まで緩和できる値です。 QA Cでは 10, 30 ,100というデリミタを設けて 3段階の警告メッセージを表示します。 キビアット図では一番厳しい 10を最大値に設定しています。
STPTH 可能性がある経路数の上限値。
Nejmeh(1988)および Hattonと Hopkins(1989)の研究で、 パスカウントが 200~300 を超えると メンテナンス上問題が発生することが指摘されています。
また、AT&Tでは 200が保守費用曲線の変化点となるという認識をもっています。
QA C では、200, 1000, 100000というデリミタを設けて 3段階の警告メッセージを表示します。 ご提案できる静的経路数の値 は200~1000 だといえます。1000 を超えるものについては承認付きのものに限り、 手動によるテストを行う必要があります。
STMIF 制御構造の最大ネスティング数。
ANSIの規格では各ネスティングレベルの最低規定値(限界)がレベル 15と設定されています。 main(){{{{{{{{{{{{{{{}}}}}}}}}}}}}}}
Hattonは、取り扱ったソースコードの全体をネスティングレベルが悪い順に 11段階に分けると 平均 121, 4, 3, 2, 2, 1, 1, 1, 0, 0, 0 になったと述べています。 121という極端な値を除外して、そこから 5という値が算出されています。
STSUB 関数呼び出し数。
Brandl(1990)の論文で複雑度と関数のコーリングツリーの形状を明らかに しているようです。 (弊社にこの論文がないので未確認です)入手可能でしたらそちらをご参考ください。
Brandl.D L(1990)"Quality measures in design", ACM Sigsoft.Software Engineering Notes, vol 15, no.1
STLIN 関数の { から } までの行数。
Thomas Plumは関数の行数が50行を超えないよう推奨しています。 QA Cでは50を超えると警告メッセージを表示します。


参考資料は以下の通りです。

1. Hatton Les, 「Safer C: Developing Software for High-integrity and Safety-critical Systems」- (McGraw-Hill International Series in Software Engineering)
I. Title II Series 005.133 ISBN 0-07-707640-0

2. QA C製品概要書

3. QA Cコマンドラインマニュアル
コマンドラインマニュアルに、おおよその算出根拠、参考論文が記述してあります。 "QA C version 4.0 Command line"マニュアルの付録(189,190ページ)に理想値が載っていますので, そちらを参照して下さい。
  日本語版:”QA C ver4.0 コマンドライン 189,190ページ”を参照下さい。
  英語版:”QA C ver4.0 command line Page 193,194”を参照下さい。



質問2. ソースコードの行数に関するメトリックスの定義を教えて下さい 。

QA C,QA C++ 提供されているソースコードの行数に関するメトリックスの定義を詳しく教えて下さい。
戻る
回答2.

代表的なメトリックスの標準値を示します。
Version: 4.0.3J, 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

行数の計算に関するPRL情報です。

[フ]=ファイル・メトリックス
[関]=関数メトリックス

[フ]STTPP プリプロセス前の行数
ファイル適用範囲にあるファイル内のソースコードの総行数
[フ]STTLN プリプロセス後の行数プリプロセスを経て、マクロ定義等を展開した後の総行数
[関]STLIN 保守可能なコード行数
空白行、コメントや大カッコのみの行を含まない関数の定義部分の行数
関数内('{'と'}'の間)に書かれている全ての行数
[関]STXLN 実行コード行数
STLINから宣言部分を除いた行数
関数内の全ての実行行を数えたもので、以下のものは数えません。
※コメントのみの行、空行、'{'または'}'のみの行、宣言行

以下は、PRLが作ったテクニカルガイドの抜粋です。
M11 コード行数 CANTATA
QA C
QA C++
McCabe
関数ベースとファイルベース
関数ベース
関数ベース
関数ベース
(尺度:絶対値 単位:行)
CANTATAではコード行数のことを関数ベースの時には CODE_LINESと呼び、 ファイルベースの時には FILE_CODE_LINESと名づけています。
コード行数は、関数の最初の大カッコから最後の大カッコまでの行数と変数宣言部分の行数を含んでいます。
関数ベースでは、QA Cや QA C++はこのコード行数のことを STLINと名づけており、空白行、コメントのみの行、 大カッコのみの行は含まない関数の定義部分の行数として数えます。
4つツール全て、計算はプリプロセス前のコードに対してなされます。
CANTATAによってなされる計算はMcCabeによってなされる計算と同じです。 しかし、QA CとQA C++では計算方法が異なっているので矛盾が生じます。
M11が200を超えるものについて全ての関数を調査してください。 200行より小さく、かつ十分に空白行やコメントがあるような関数を書いてください。 スペースを追加することが可読性を上げるのかどうか評価するにはM11を使ってください。
 
M13 実行行数 QA C
QA C++
McCabe
関数ベース
関数ベース
関数ベース
(尺度:絶対値 単位:行)
QA Cと QA C++ではこの統計値を STXLNと名づけ、各関数について計算します。
実行行数は M11から宣言の行数を引いた値です。
多くのコーディング標準は M13は50を超えてはいけないと要求しますが、150という限界値の方が現実的です。
もし関数の実行行数が150以上なら、関数を調査し、M13を150以下にするように関数を修正してください。
なぜそうなったかという明らかな技術的理由がある場合には、責任者に品質に関して譲歩する許可をもらい、 コードが標準に満たないで譲歩しているものだというドキュメントをつけてください。
 
M15 プリプロセス前のソース行数 CANTATA
QA C++
McCabe
関数ベースとファイルベース
ファイルベース
関数ベース
(単位:行)
M15はファイル中のプリプロセス前のソースコードの総行数のことです。
QA Cと QA C++ではこの値はファイルの適用範囲で計算し、STTPPと名づけています。
CANTATAではこの値をファイルの適用範囲では FILE_SOURCE_LINESと名づけ、 関数の適用範囲ではSOURCE_LINESと名づけています。
この値はファイル適用範囲のファイルのソース総行数か関数適用範囲内の関数の総行数です。
M15はユーザが書いたコードの大きさを測定するもので、多くの方法論で(例えば、 COCOMOコストモデル)コードの外部属性の予測要因として使用されます。 例えば、ライフサイクルの後半段階で必要な時間や労力といったものです。
研究は、広い範囲にわたり単体の測定値でなく使用されている製品の測定値の方が、 工程や資源の測定値を予測をするには一貫し てM15より有益だと示しています。
しかしながら1つの製品の測定値を該当する工程や資源の測定値の一般的な予測要因として使用することは あまりお勧めできません。
コードがプロセッサに依存しているかどうかを評価するには M16と M15を使ってください。
もし、後半の工程や資源の測定値を予想しなければいけない時には、 このガイドに記述している他の測定値よりはむしろM15の予測値を基本にしてください。
ただし、この予測値は特に優れた予測要因ではないことに注意してください。
 
M16 プリプロセス後のソース行数 QA C
QA C++
ファイルベース
ファイルベース
(尺度:絶対値 単位:行)
M16はファイル中のプリプロセス後のソースコードの総行数のことです。
M16自身ではとくに測定値としては使用しません。 しかしながら、コードがプロセッサに依存しているかどうか評価する時には M15と合わせて使用します。
Cではプロセッサへの依存が高いと、コードの移植性が悪くなります。
C++ではコンパイラが型のチェックをすることができない構築子の使用の前兆でもあります。
M16/M15は4を超えてはいけません。もし4を超えてしまったらコードはプロセッサに依存しすぎだといえます。
そのようなコードやM16やM15がきわめて高い値を示しているコードは プロセッサに依存していることから生じる潜在的な問題がないかどうか調べてください。 そして、見つかった明らかな問題点はすべて修正してください。

 


質問3. STSCT、および STECTのカウント方法を教えてください。

ファイルメトリックス「宣言した静的変数の数:STSCT」は、製品概要書によりますと、宣言したスタティック変数の数とありますが、実際どのようにカウントするのでしょうか?(グローバルも含めてでしょうか?コーディング例も例示下さい)
同じく、ファイルメトリックス「宣言した外部参照変数の数:STECT」も、どのようにカウントするのか教えてください(コーディング例も例示ください)
戻る
回答3.

宣言した静的変数の数、宣言した外部参照変数の数をカウントします。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

静的変数の総数 (STSCT) は、ファイルスコープで static という記憶クラス指定子を使用して宣言されている識別子 (変数、関数) の数です。

また、宣言した外部変数の総数が、STECTとしてカウントされます。

前者、後者のメトリックとも1つのファイルが有効範囲(スコープ)です。
外部変数の場合、同じ変数名でいくつのファイルに宣言されている場合、それぞれのファイルで STECTにカウントされます。

また、オプション -ppm(メトリックスを測定するタイミングをプリプロセスの前後どちらにするか指定するオプション)の設定によって、これらの値は変化します。

-ppm-の場合(メトリックスをプリプロセス前に測定)

  宣言されている静的変数の総数 (STSCT) 1
   宣言されている外部変数の総数 (STECT) 2

-ppm-の場合(メトリックスをプリプロセス後に測定)

  宣言されている静的変数の総数 (STSCT) 3
   宣言されている外部変数の総数 (STECT) 3

(例)

test.h

1: int DDD;
2: static int EEE;
3: static int bar(void);

test.c

8: #include "test.h"
9:
10: static int AAA;
11: extern int BBB;
12: int CCC;
13:
14: int foo(void);
15:
16: int foo(void)
17: {
18:  static int x;  /* 関数スコープの static識別子は数えない */
19:
20:  return 1;
21: }


質問4. STVOL(プログラム規模)について、バイト換算で示したいときは、 STVOLの値を 8で割ればよいですか?

以下に示すメトリック項目の解釈は正しいかどうか教えて下さい。

STVOLについてバイト換算で示したいときは、STVOLの値を 8で割ればよいですか?


戻る
回答4.

STVOLはバイト換算も、8で割る必要もないと思われます。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

STVOL(プログラム規模)は、下式で表わされます。

  STVOL = n × log2(t)

ここで n = STTOT(トークンの総数)
      t = t1 + t2

なお t1 = STOPT(異なった演算子の数)
     t2 = STOPN(区別可能なオペランドの数)

上式の通り、STVOLは STTOT(トークンの総数)に比例しますが、 STTOT自体は長さの長いトークンも短いトークンもそれぞれ1個として数えたものの総数ですので、ここに「バイト」という概念は入りません。

また、log2(t) の項が含まれていることからおわかりの通り、 STVOLは行数の長さだけでなく、いかに多くの種類の演算子やオペランドが含まれているか、という点が加味された上で算出されます。これは、多くの種類の演算子やオペランドが使われている場合は、それだけ難しいコードを作っているという前提に基づいています。トークン数がほぼ同じで、同じ論理を実現する2種類のプログラムを作った場合、変数の種類を多くしただけで、上式のnの項が増加して、STVOLが増加しますのでお試し下さい。

ご質問に「バイト換算」という表現がありますが、別に8バイト単位で算出している値ではありませんので、バイト換算も、8で割る必要もないと思われます。


質問5. STLIN(保守可能なコード行数)は、関数の総ステップのことですか?

STLINは、関数の総ステップ(コメント行も含む?)のことですか?
(STXLNが基本的には、STLINから宣言文の行数を引いたものとありますが。)
戻る
回答5.

関数の総ステップを数えます。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

QACでは、ステップ数(=行数)を示すメトリックスとして、以下の4種類を備えています。
([関]=関数メトリックス、[フ]=ファイルメトリックス)

(1)[フ]STTPP:プリプロセス前の行数
    ファイル内の全ての行数を数えたものです。

(2)[フ]STTLN:プリプロセス後の行数
    プリプロセスを経て、マクロ定義等を展開した後の総行数です。

(3)[関]STLIN:保守可能なコード行数
    関数内('{'と'}'の間)に書かれている全ての行数を数えたものです。

(4)[関]STXLN:実行コード行数
    関数内の全ての実行行を数えたもので、以下のものは数えません。
    ・コメントのみの行、空行、'{'または'}'のみの行、宣言行

よって、ご指摘通り「関数の総ステップ(コメント行も含む)」を数えます。


質問6. STPBGの値は、テスト時に消化したバグ数との比率として活用するのですか?

STPBGの値は、潜在すると思われるバグの数で、テスト時に実際に見つけられるバグ件数ではないのでしょうか?

あくまでも、テスト時に消化したバグ数との比率として活用するものなのでしょうか?


戻る
回答6.

「テスト時に消化したバグ数との比率として活用する」のは非常に良いアプローチだと思います。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

STPBG(潜在バグ見積)は、下式で表わされます。

STPBG = log10(STPTH)

よって、STPTH(静的経路数)の対数を求めただけのものです。この仮定が成り立つには、経路数の対数とバグ数が比例する、という大胆な前提が真である必要があります。一般論として、静的経路数が高い関数に多くのバグが潜むということについては、どなたも異存はないところだと思われますが、実際の関数レベルで考えると、同じ経路数を示す複数の関数間でも、実に様々な違いがあるかと思います。

ご指摘の通り、「テスト時に消化したバグ数との比率として活用する」のは非常に良いアプローチだと思います。

既にお気づきかもしれませんが、QA Cのメトリックスは非常に大胆な仮定をしているものが多くあります。C言語の性格や傾向をより精密に求めようとすると、いろいろな項目が気になって、なかなか数字として表わす段階に行かない、という経験をお持ちではありませんか。 QA Cのメトリックス値は、自社の複数のコードの実測値との間の相関関係をプロットできるだけのサンプル数が揃った時点で、「細かいファクターを挙げればきりがないが、大局的に見ればこのファクターと比例関係があると判断できる」という観測をしていただくのにお使いいただけると思います。

実測値との比例係数を求めるアプローチが成功しているユーザの数は、まだ多くはありません。これは、実際に開発中のコードを持っていない弊社ではできないことで、お客様に是非蓄えていただきたいデータです。


質問7. プログラム難易度(STDIF)が小、流用度(STMOB)が良、プログラム規模(STVOL)が小なのに、バグ見積(STBUG)が非常に大きい理由はなんですか?

1.経緯

分野ごと代表のプロジェクトファイルをQA Cにかけました。その結果、ファイルの方でプログラム難易度(STDIF)、流用度(STMOB)、プログラム規模(STVOL)、バグ見積(STBUG)を抽出し、関数の方では、STCYC STMIF STXLN STXLN STPTH STPBGを抽出し、見比べました。

2.疑問点

その中で、あるプロジェクトが、プログラム難易度(STDIF)が小、流用度(STMOB)が良、プログラム規模(STVOL)が小なのに、バグ見積(STBUG)が非常に大です。

この理由がほしいのです。他にどんな要因が考えられるのか、また、どんな要因をなくせば、バグ見積は減少するのか、知りたいと思います。


戻る
回答7.

STBUGは、オペランド数(STOPN)または変数の数(STVAR)が大きいと、大きな値になります。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

拝見したファイルの中の STBUGを見る限りは、1ファイル当り特別に大きな STBUGが出ている例は見当たりません。せいぜい多くても1か2程度のようです。

STBUGの定義を今一度コマンドライン・マニュアルでご確認いただきたいのですが、STBUGは、オペランド数(STOPN)または変数の数(STVAR)が大きいと、非常に大きな値となってきます。外部変数の数(STECT)が桁違いに大きい場合、それが足を引っ張ります。

各ファイルについて、STOPN, STVAR, STECTの各値をチェックしてみて下さい。バグ見積(STBUG)が大きいファイルは、外部関数の定義部が非常に大きな場所を占めている形になっていると思います。

QA Cの STBUGは、その算出基準から見て、多くの種類の定義が入ったファイルに対しては大きな値を示すようにできています。しかしながら、これが直ちに、外部変数を使うのは好ましくない、という風に短絡することはできないことは、ソフトウェアを作成される方ならおわかりいただけるところで、論理を記述する上で必要であれば、それを削ってまで QA Cの成績を上げることのみを優先する必要はありません。ただ、一般論として、あまりにも多くの外部変数を必要とする場合には、やはり保守性の面で難があることは否定できませんが‥‥

強調しておきたいのは、STBUGが「バグ見積」と名前が付いているからと言っても、これが「バグが必ずxx個あります」という指標ではない、ということです。

各メトリックスは、複雑なソフトウェアの「品質」を極力単純な数式で代表させることはできないか、という観点で各研究者が知恵を絞ってきた事柄です。よって、アンプの世界と同様に、自ずから有効な帯域というものがあります。全体の8割位の解析対象に対して、実感と近い値が出ていれば、それで十分と考えて下さい。

例えば、イベント駆動型のプログラムでは、少なくとも1箇所は大規模な switch-caseによるイベント分岐が存在し、非常に大きな経路複雑度(STCYC)を持ちます。

しかし、この関数を STCYCを下げるためだけに、switch-caseを分割するとしたら、それは無茶というものではないでしょうか。また、経路複雑度(STPTH)については、たった1つの関数の STPTHが 50,000,000を示しただけで、他の関数の STPTHが良好であっても、平均値を求めると、とてつもなく大きな値になってしまいます。

よって、各メトリックスの算出基準を理解し、どのファクターが大きい(小さい)と極端な値を示すか知った上で、該当するファイル(関数)において、そのファクターが大きい(小さい)ならば見逃す、というような運用を貴社で徐々に積み上げていただければ、と思います。今後、QA Cのメトリックスを活用していただくに際して、現実の数値と QA Cの 出力値とを、絶えずペアで蓄積していただくことをお勧め致します。

貴社におかれましても、独自の算出方法で各種の実測値を算出されていらっしゃる ことと思います。すぐには相関関係は見出せないとは思いますが、一方に実測値、 他方に QA Cの出力をプロットした場合、 (縦横はどちらでも構いませんが)相互に 1次関数で近似できたり、対数を取ると比例関係が見出せることがあります。 そこまでデータが蓄積できたら、近似式 Y=aX+b の係数 a, bを求めてみて 下さい。QA Cの出力値を、貴社の実測値の尺度に合わせることができます。


質問8. STNTB, STTKB, STBCS, STCOMの数値が出力されません?

現在、QA Cの出力するメトリックスの利用方法を検討しておりますが、ファイルベースのメトリックスにおいて以下の数値が出力されません。

STNTB
STTKB
STBCS
STCOM


戻る
回答8.

4つのメトリックはデリミタに相当する識別子で、それ自体に値はありません。 Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

Analyze.metを例に示します。4つのメトリックはデリミタに相当する識別子で、それ自体に値はありません。

その意味を以下に示します。

STNTB:ここからは、非トークンベースのメトリックスです
STTKB:ここからは、トークンベースのメトリックスです
STBCS:ここからは、COCOMO統計を元にしたメトリックスです
STCOM:ここからは、コメントベースのメトリックスです

Analyze.met
<S>
<S>STFIL C:\QACJ\demo\Analyze.c
<S>STNAM C:\QACJ\demo\Analyze.c
<S>STNTB NON-TOKEN BASED STATISTICS...
<S>STSCT 10
<S>STECT 48
<S>STFNC 8
<S>STFCO 52
<S>STTKB TOKEN BASED STATISTICS...
<S>STVAR 452
<S>STOPT 66 (t1)
<S>STOPN 857 (t2)
<S>STTOT 7767 (n)
<S>STZIP 6835
<S>STHAL 8749
<S>STSHN 35662
<S>STDIF 19.09
<S>STEFF 1460659
<S>STVOL 76506
<S>STDEV 243.44
<S>STPRT 9.24
<S>STMOB 96.20
<S>STBUG 13
<S>STTPP 924
<S>STTLN 774
<S>STBCS BASIC COCOMO STATISTICS...
<S>STBMO 2.209
<S>STBMS 2.746
<S>STBME 3.274
<S>STTDO 3.378
<S>STTDS 3.560
<S>STTDE 3.654
<S>STCOM COMMENT BASED STATISTICS...
<S>STCDN 0.768


質問9. STUNVで指摘された変数名を表示する方法はありますか?

STUNVで指摘された変数名を表示する方法はありますか?

* 現在、解析はコマンドラインで行っております。


戻る
回答9.

3205と3206番のメッセージの数をカウントします。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

STUNV(関数単位で測定するメトリック)でカウントされるのは、カテゴリ2の「メンテナンスの問題」に含まれる3205と3206番のメッセージの個数です。

3205 変数 '%s'はその有効範囲(scope)で使用されていません。削除可能です。
3206 引数 '%s'はこの関数では使用されていません。

これらは注釈つきソースコード(list.qac)で表示されます。こちらをご覧いただきますと、変数名がわかります。

また、static変数については、関数単位で測定するメトリックではありませんので、使用されていない場合でも STUNVにはカウントされません。未使用の場合、3207番のメッセージでのみわかります。(例10行目を参照ください)

3207 'static'と宣言された変数'%s'は使用されていません。削除可能です。

static変数に関するメトリックは(ファイル単位で測定するメトリックのうちの) 宣言されている静的変数の総数 (STSCT)です。

(例)
6: #include
7:
8: #include "test.h"
9:
10: static int AAA;
          ^
C:\src\test.c(11) ++ WARNING ++: <=2=(3207) 'static'と宣言された変数'AAA'は使用されていません。削除可能です。
11:
12:
13: int sub_asm1(short param1, short param2)
                         ^
C:\src\test.c(13) ++ WARNING ++: <=2=(3206) 引数 'param2' はこの関数では使用されていません。
14: {
15:  int iParam;
16:  int k;
       ^
C:\src\test.c(16) ++ WARNING ++: <=2=(3205) 変数 'k'はその有効範囲(scope)で使用されていません。削除可能です。
17:  int j;
       ^
C:\src\test.c(17) ++ WARNING ++: <=2=(3205) 変数 'j'はその有効範囲(scope)で使用されていません。削除可能です。

...

36: return iParam;
37: }


質問10. STUNVにカウントされる変数のうち、「再利用されていない変数」の意味を教えてください

STUNVにカウントされる変数のうち、「再利用されていない変数」とありますが、この「再利用」という意味がマニュアルを見てもよく分かりません。具体的な例を提示していただけるとありがたいのですが・・・
戻る
回答10.

関数のパラメータとして設定(set)されたが関数内部で使用されていないという意味です。
Version: 4.2J
OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

コマンドラインマニュアル(p77)のSTUNVの説明に「未使用および再使用されていない変数の数」とあるのは、

未使用:回答1の(例)16,17行目のように宣言されたが使用されていない
再使用:回答1の(例)の13行目のように関数のパラメータとして設定(set)されたが関数内部で使用されていない

という意味です。

STUNVの定義が英語のコマンドラインマニュアルで、"The number of unused and non-reused variables" となっている以上「未使用および再使用されていない変数の数」という日本語になってしまうことをご了承いただけないでしょうか。