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

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

[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つで書かざる得ないが。
(でも、こういう例では、途中から抜けるような処理はご法度かなぁ。)

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

[masas (1835)]

Cでロックを安全にするときってこう書きませんか？

static int lfunc()
{
...
    if (statement_stands)
    {
        return;
    }
...
}
 
int func()
{
    lock();
    lfunc();
    unlock();
}

Re:

[Anonymous Coward]

名前空間を汚さない為にstaticを使った点と、
呼び出し元で戻り値を無視した点を評価したい。

# 余計なものではないのです!(嘘

そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題)

[Anonymous Coward]

>int func()

って書いたんだから、

> return;

に、リターンコード指定しようよｗ

Re:そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題)

[SHNSK (10099)]

あ....

Re:

[Anonymous Coward]

入力エラー処理などは途中リターンを入れたほうが読みやすいし、書きやすいこともあるから一応にそうとはいえないと思われ。

ついでに、
もし、C++で書いているんだったら、lock unlockはデストラクタで解決してくれと思う。
Cで書いているなら、 do{ }while(0); でがんばるか、エラー部分だけは例外的に goto err で抜けるとかがいいと思う。

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

[SHNSK (10099)]

はい，僕は普段は C++ を使っているので，そんな風にやっていますね：

struct DoUndoLock {
    DoUndoLock() { lock(); }
    ~DoUndoLock() {unlock(); }
}

void func()
{
    DoUndoLock locker;
    ...
    if (statement) {
      ...
      return;
    }
    ...
    return;
}
みたいな．

Re:

[Anonymous Coward]

デストラクタで例外が発生する可能性のある処理をするのは...

Re:

[Anonymous Coward]

まぁ、C++の例外なんて飾りみたいなもんだし

Re:

[Anonymous Coward]

デストラクトするのが目的なんだから、

>デストラクタで例外が発生する可能性のある処理

例外が出るからといって回避してしまっては無意味でしょ。

例外が出たときにそれをなんとか片付ける手段をどこかで用意しないとならない、というだけのことだと思う。

そして、それが「不可能」な場合は、その環境下で作ったソフトは「使い物にならない」というだけのこと…であることがしばしば有ると思われ。

＃作りたいソフトが常に「作れる」とは限らないんだよね。

Re:

[Anonymous Coward]

関数途中のreturnを禁止しているなら、ほぼ間違いなくgotoは禁止しているはずですよ。