「静的プログラム解析ツールの実力は？」記事へのコメント

出てくる警告にどう対処するのかが問題

[okky (2487)]

警告を無視したり、出てくる指摘に「逃げる」ようなコードで対処するプログラマばかりの世界では、まったく品質は向上しない。そして困ったことにそういう所こそ、品質を向上させなくてはいけない元凶だったりする。

# しかも、周りがヤイのヤイの言っても、今まで一度も直らなかったぐらい
# 上から下まで、ものを判っていない。

というわけで、このようなツールを使ったからどう、という事ではありません。
このようなツールの出力にどう対処するかが問題。また、このようなツールが
出してくる警告の量から、プログラム改善にかかる時間を正確に見積もる、などの
マネージメント能力も大事でしょう。

--
fjの教祖様

Re:

[Anonymous Coward]

組み込みプログラマの吹き溜まり自動車業界には MISRA C という C 言語コーディング上のお約束集があるのですが、こいつに書いてあることのいくつかはどうにも腑に落ちません。
中でも最凶最悪なのは、関数の途中での return 禁止というものです。
枝刈りして関数を抜けたいのに、フラグを引き回して入れ子が深くなって読みづらいのです。
なにが嬉しくて可読性を落とすのか。教えて！エロイひと！

Re:

[SHNSK (10099)]

組み込みとかは一行も書いたことはないですが，関数の途中で return 禁止にしておくと防げそうなバグは思いつきます：

int func()
{
    lock();
...
    if (statement_stands)
    {
        /* ここでロックをはずすのを忘れる */
        return;
    }
...
    unlock();
    return
}

とか．

Re:出てくる警告にどう対処するのかが問題

[USH (8040)]

こういうのは、こうかくのでねえのか？

int func()
{
  lock();
  int r = func_body() ;
  unlock();
  return r ;
}
 
int func_body()
{
  ...
  if(statement_stands)
  {
    return 1 ;
  }
  ...
  return 0;
}

Re:出てくる警告にどう対処するのかが問題

[Anonymous Coward]

ロック対象が増えた場合に見通しが悪くならね？

int func()
{
    lock1();
...
    if (statement_stands)
    {
        unlock1();
        return;
    }
...
    lock2();
...
    if (statement_stands)
    {
        /* ここでロックをはずすのを忘れる */
        unlock1();
        return;
    }
...
    unlock2();
    unlock1();
    return;
}

↓　↓　↓　↓　↓　↓　↓

int func()
{
  lock1();
  int r = func_body1() ;
  unlock1();
  return r ;
}
 
int func_body1()
{
  ...
  if(statement_stands)
  {
    return 1 ;
  }
  ...
  lock2();
  int r = func_body2();
  unlock2();
  return r;
}
 
int func_body2()
{
  ...
  if(statement_stands)
  {
    return 1;
  }
  ...
  return 0;
}

Re:出てくる警告にどう対処するのかが問題

[USH (8040)]

ロック対象が増えた場合に見通しが悪くならね？

ロック対象が増えた段階で、プログラム上、無理がなければ、すぐに関数を分けてしまう方なので、あまり気にならないなぁ。

lock1();
...
lock2();
...
unlock1();
...
unlock2();

のような場合は1つで書かざる得ないが。
(でも、こういう例では、途中から抜けるような処理はご法度かなぁ。)