アカウント名:
パスワード:
C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。
> 関数の末尾以外の return を禁止する
なぜ禁止なのかわからない人にコードは書かせたくないなあ
なぜ禁止すべきでないのかわからない人にコードを書かされたくないなあ。# 論理的な理由があるならそれを書けば済むだけなのに決まってこんな罵倒しか返ってこないんだよな
途中で return すると、リソース解放し忘れるミスが増えるから。コードの見通しの悪さによる保守性悪化と、リソースリークの潜在的危険性を天秤にかけた。理由としてはそれだけ。
MISRA C の主目的は深刻なバグの入りやすいパターンを避けることだから大多数にはバカバカしいルールでも、たった一人の間抜けに躓かないための妥協が多くなる。
C にデストラクタがあればこんなルールは生まれないね。
その関数が一人の人間が見通しの良い行数以内で一度書いて完成、以降の改造も未来永劫ないとは限りませんから。
「そこだけ禁止」言うは易し、行うは難し。文脈に依存したコーディング規約の適用はすぐに破たんする。たとえば、リソースを使っていなかったモジュールを後から使うように変えたら、途中 return は全部書き換えるのか。
そもそも管理リソースを減らしたくて一律に適用しているのだから、本末転倒。
MISRA C使っている業界は工数に占めるコーデングとテストの割合が10%未満だしなあ。大体数年かけて、仕様策定に50%弱、出荷前までのレビューに同じく50%弱使って、設計とコーディングとテストは残り工数でやる感じ。常に10件以上の開発が並行して走っていて兼務するため、いちいち覚えておけないので毎回その場で把握と問題解決をする。
残念ながらMISRA C++というC++に対応したとされるものがありまして、それにも変わらずばかばかしいルールが残ってるんですよね
たった一人の間抜けはどんな規約を用いても深刻なバグを作りこむのであまり意味がないのでは。むしろ、保守性が悪化することでリソースリークが起こりやすくなる場合もありますし(実際そういうソースに出会ったこともあります)。
> 大多数にはバカバカしいルールでも、たった一人の間抜けに躓かないための妥協が多くなる。
間抜けに躓かないのを基準にルールをつくると、本来不要なルールがいくらでも増えていく。コードの健全性を期待するなら lint みたいなチェッカで評価するのを標準化するほうがより適切かと。
> C にデストラクタがあればこんなルールは生まれないね。
C でデストラクタ相当の処理を設けたいなら、リソース割当と解放をする呼び出し関数を経由するんじゃないかな。
コードの健全性を期待するなら lint みたいなチェッカで評価するのを標準化するほうがより適切かと。
そんなツールが手軽に使えれば、泥臭いデザインパターンみたいなコーディング規約に頼らなくてもいいのだが。無いものねだりは仕方がない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
MISRA C という失敗 (スコア:1)
C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、
関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。
役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。
Re: (スコア:1, すばらしい洞察)
> 関数の末尾以外の return を禁止する
なぜ禁止なのかわからない人にコードは書かせたくないなあ
Re: (スコア:0)
なぜ禁止すべきでないのかわからない人にコードを書かされたくないなあ。
# 論理的な理由があるならそれを書けば済むだけなのに決まってこんな罵倒しか返ってこないんだよな
Re:MISRA C という失敗 (スコア:1)
途中で return すると、リソース解放し忘れるミスが増えるから。
コードの見通しの悪さによる保守性悪化と、リソースリークの潜在的危険性を天秤にかけた。
理由としてはそれだけ。
MISRA C の主目的は深刻なバグの入りやすいパターンを避けることだから
大多数にはバカバカしいルールでも、たった一人の間抜けに躓かないための妥協が多くなる。
C にデストラクタがあればこんなルールは生まれないね。
Re:MISRA C という失敗 (スコア:1)
それならそこだけ禁止すればいいだけなのに、なんで全部禁止にしたがるのでしょうね?
その関数がリソース解放しているかどうかぐらい書いている人もレビューする人も分かりますよね。
Re:MISRA C という失敗 (スコア:1)
その関数が一人の人間が見通しの良い行数以内で一度書いて完成、以降の改造も未来永劫ないとは限りませんから。
Re:MISRA C という失敗 (スコア:1)
「そこだけ禁止」言うは易し、行うは難し。
文脈に依存したコーディング規約の適用はすぐに破たんする。
たとえば、リソースを使っていなかったモジュールを後から使うように変えたら、途中 return は全部書き換えるのか。
そもそも管理リソースを減らしたくて一律に適用しているのだから、本末転倒。
Re:MISRA C という失敗 (スコア:1)
当たり前ですが、何か問題でも?
全然破綻している例えになってませんよ。
>そもそも管理リソースを減らしたくて一律に適用しているのだから、本末転倒。
管理リソース削減のためにコードを難解にするほうが本末転倒だと思うのですが、
どうやらMISRA C使っている業界とは住む世界が違うようです。
Re: (スコア:0)
MISRA C使っている業界は工数に占めるコーデングとテストの割合が10%未満だしなあ。
大体数年かけて、仕様策定に50%弱、出荷前までのレビューに同じく50%弱使って、設計とコーディングとテストは残り工数でやる感じ。
常に10件以上の開発が並行して走っていて兼務するため、いちいち覚えておけないので毎回その場で把握と問題解決をする。
Re:MISRA C という失敗 (スコア:1)
残念ながらMISRA C++というC++に対応したとされるものがありまして、
それにも変わらずばかばかしいルールが残ってるんですよね
Re: (スコア:0)
たった一人の間抜けはどんな規約を用いても深刻なバグを作りこむのであまり意味がないのでは。
むしろ、保守性が悪化することでリソースリークが起こりやすくなる場合もありますし(実際そういうソースに出会ったこともあります)。
Re: (スコア:0)
> 大多数にはバカバカしいルールでも、たった一人の間抜けに躓かないための妥協が多くなる。
間抜けに躓かないのを基準にルールをつくると、本来不要なルールがいくらでも増えていく。
コードの健全性を期待するなら lint みたいなチェッカで評価するのを標準化するほうがより適切かと。
> C にデストラクタがあればこんなルールは生まれないね。
C でデストラクタ相当の処理を設けたいなら、リソース割当と解放をする呼び出し関数を経由するんじゃないかな。
Re:MISRA C という失敗 (スコア:1)
コードの健全性を期待するなら lint みたいなチェッカで評価するのを標準化するほうがより適切かと。
そんなツールが手軽に使えれば、泥臭いデザインパターンみたいなコーディング規約に頼らなくてもいいのだが。
無いものねだりは仕方がない。