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

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

[okky (2487)]

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

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

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

--
fjの教祖様

Re:

[Anonymous Coward]

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

Re:

[SHNSK (10099)]

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

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

とか．

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]

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

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

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

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

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

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