アカウント名:
パスワード:
int func(){ lock(); int r = func_body() ; unlock(); return r ;} int func_body(){ ... if(statement_stands) { return 1 ; } ... return 0;}
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;}
ロック対象が増えた場合に見通しが悪くならね？
static int lfunc(){... if (statement_stands) { return; }...} int func(){ lock(); lfunc(); unlock();}
int func(){ int retcode = 0; do{ /* ==== 条件チェック ==== */ if(何かの条件){ retcode = -1; break; } /* ================ 処理本体 ================*/ }while(0); return retcode;}
returnがダメならgotoを使えばいいじゃない。
マジレスするとエンバグの危険を減らしてトータルの手間を減らすのが嬉しくて可読性を落とすのでしょう。 その規約によって実際に「エンバグの危険が減っているか」、あるいは「(誰かにとって)可読性が落ちているか」はまた別の話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
出てくる警告にどう対処するのかが問題 (スコア:5, すばらしい洞察)
# しかも、周りがヤイのヤイの言っても、今まで一度も直らなかったぐらい
# 上から下まで、ものを判っていない。
というわけで、このようなツールを使ったからどう、という事ではありません。
このようなツールの出力にどう対処するかが問題。また、このようなツールが
出してくる警告の量から、プログラム改善にかかる時間を正確に見積もる、などの
マネージメント能力も大事でしょう。
fjの教祖様
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 興味深い)
中でも最凶最悪なのは、関数の途中での return 禁止というものです。
枝刈りして関数を抜けたいのに、フラグを引き回して入れ子が深くなって読みづらいのです。
なにが嬉しくて可読性を落とすのか。教えて！エロイひと！
Re:出てくる警告にどう対処するのかが問題 (スコア:3, 興味深い)
int func()
{
lock();
...
if (statement_stands)
{
/* ここでロックをはずすのを忘れる */
return;
}
...
unlock();
return
}
とか．
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 参考になる)
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
ロック対象が増えた段階で、プログラム上、無理がなければ、すぐに関数を分けてしまう方なので、あまり気にならないなぁ。
lock1();
...
lock2();
...
unlock1();
...
unlock2();
のような場合は1つで書かざる得ないが。
(でも、こういう例では、途中から抜けるような処理はご法度かなぁ。)
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
Re: (スコア:0)
呼び出し元で戻り値を無視した点を評価したい。
# 余計なものではないのです!(嘘
そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題) (スコア:0)
って書いたんだから、
> return;
に、リターンコード指定しようよｗ
Re:そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題) (スコア:1)
Re: (スコア:0)
ついでに、
もし、C++で書いているんだったら、lock unlockはデストラクタで解決してくれと思う。
Cで書いているなら、 do{ }while(0); でがんばるか、エラー部分だけは例外的に goto err で抜けるとかがいいと思う。
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
struct DoUndoLock {
DoUndoLock() { lock(); }
~DoUndoLock() {unlock(); }
}
void func()
{
DoUndoLock locker;
...
if (statement) {
...
return;
}
...
return;
}
みたいな．
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
>デストラクタで例外が発生する可能性のある処理
例外が出るからといって回避してしまっては無意味でしょ。
例外が出たときにそれをなんとか片付ける手段をどこかで用意しないとならない、というだけのことだと思う。
そして、それが「不可能」な場合は、その環境下で作ったソフトは「使い物にならない」というだけのこと…であることがしばしば有ると思われ。
＃作りたいソフトが常に「作れる」とは限らないんだよね。
Re: (スコア:0)
Re:出てくる警告にどう対処するのかが問題 (スコア:2, 興味深い)
MISRA-Cってのは自分で適切なルールを選んで適用するものです。
ですから、関数途中のreturnを禁止するとうまくない理由をちゃんと説明して
そのルールを外してもらうのがMISRA-Cのやり方です。
外してもらえないのなら、あなたの説明が悪いか、ボスand/or顧客がアレなのか、どちらかあるいは両方です。
MISRA-Cは正しいのですｗ
Re: (スコア:0)
最近もあんまり理由のないルールに従わされたおかげでエンバグして大騒ぎになった事が。
プロジェクトごとに要員のスキルやプロジェクトの性質を考えてルールを取捨選択すれば幸せなのに、それができない人に使わせると容易に大惨事を引き起こせる、そんな道具だから。
sfrへのアクセスに直アドレスのポインタを使わないといけないコンパイラなのに、ポインタに整数値入れるなってルールを適用して警告だらけで他のルールが埋もれるって何よ(泣)
しかも提供されたsfr定義ファイル使ってるのに(怒)
Re: (スコア:0)
エロい人は出てくるな！
そうやって前置きされると、静的とか正規表現とか聞くだけで
英語の辞書を渡され速攻で[S]の項を調べた日々が蘇って困る！
＃SE(システムエンジニア)じゃないよ？
Re: (スコア:0)
某所では、MISRA-C 規格を逸脱するコードを記述する場合には、個別にその記述をする理由書を書けという運用でした。
読みやすいコードを書くことは品質を高く保つのにかなり重要だという考えなのですが、残念ながら私には意見する権利はありませんでした。
コードを読みやすくするために書類を何枚も書くというのは嫌がらせにしか思えず、読みやすいコードを維持するという考えは放棄しました。
読みづらい規約だらけでコードを積み上げましたので、もしかするとまだ想定外の問題も残っているかもしれませんが、戦線離脱した私が保守することはないので、言葉は悪いですが知ったことではありません。
引き継いだ方、後はよろしくお願いします。
自分の関わった商品を買いたいとも使いたいとも思えないのは残念です。
Re: (スコア:0)
そう思わなければいいんです。
それは「自分を操った何者かが作った商品」なのです。
＃そんな商品ばかりだったので AC orz
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
メモリリークやハンドルリークなんかは場所の特定がたいへんに面倒なので、コーディングレビューで出来るだけ潰しておきたいというのは考え方としてはありだと思うけど。
クラス使ってるとデストラクタでカバーできるんでかまわないんでしょうけど、組み込みではそうもいきませんし。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 興味深い)
＃最初に見たとき意味わかんなくて「このループ必要ないよね」と思ってがしがし書き換えてました。
Re: (スコア:0)
IDEではない場合や、まったく知らない人のコードを読む場合はわりとよみやすいこともあります。
最も変数宣言が関数の上のほうにかならずあること、というのが前提ですがスタックサイズを把握しやすいのでこれはこれでありだとは思います。
親コメントの話している層だとそもそもC言語が適していないものだと思われます。
Re: (スコア:0)
returnがダメならgotoを使えばいいじゃない。
マジレスするとエンバグの危険を減らしてトータルの手間を減らすのが嬉しくて可読性を落とすのでしょう。 その規約によって実際に「エンバグの危険が減っているか」、あるいは「(誰かにとって)可読性が落ちているか」はまた別の話。
Re: (スコア:0)
Re: (スコア:0)
組み込み業界ではありませんが、同様に途中returnが禁止されてたプロジェクトで過去にやってました。
モジュールの出入り口は基本1:1にするという内部ルールと、出口が多いとトレースしづらい辛いという理由からだったと記憶してます。
で、皆が書いたのが下のようなコード。
BOOL func()
{
BOOL ret;
...
if (判定)
{
/* こっちはエラー時 */