C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、 関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。 役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。
returnの場合は様々な要因が絡むからアレだけど, 似た例ではif文とif句の違いがあります. if(a){
x = A; }else{
x = B; } とあるものは, x = if(a) A else B あるいは, x = a?A:B; の方が大抵の場合は見通しが良いですよね. 文頭から, 「あ, xになんか代入すんだな」っていうことがわかります.
MISRA C という失敗 (スコア:1)
C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、
関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。
役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。
Re: (スコア:1, すばらしい洞察)
> 関数の末尾以外の return を禁止する
なぜ禁止なのかわからない人にコードは書かせたくないなあ
Re: (スコア:0)
なんだろう?可読性がよくなる訳じゃないし。
末尾最適化されやすくなる(かもしれない)くらいしか思い浮かばないなあ。
Re:MISRA C という失敗 (スコア:2)
私じゅうあ可読性は上がると思います.
それこそ「山脈のようなコード」でなくても.
returnの場合は様々な要因が絡むからアレだけど,
似た例ではif文とif句の違いがあります.
if(a){
x = A;
}else{
x = B;
}
とあるものは,
x = if(a) A else B
あるいは,
x = a?A:B;
の方が大抵の場合は見通しが良いですよね.
文頭から, 「あ, xになんか代入すんだな」っていうことがわかります.
同じことがreturnの場合にも言えるんじゃない?
関数の最後から見て, 何を返すのかを先に知ることで,
見通しは良くなるんじゃないでしょうか?
ここまでの説明で, returnまでの長さが問題じゃないことはわかると思います.
Re:MISRA C という失敗 (スコア:2)
ごめんなさい, 変なタイポが入りました
# ○私 は : ha
# ×私 じゅうあ: jha