Q&A
Status != Stop
Status >= Stay
Status==Stay || Status==Start
はそれぞれ記述の意図するところが異なり得ると思うので，
どこぞのガイドラインでは～ みたいなことを言うよりも前に
今現在の記述になっている理由（なぜ複数の考えられる書き方の中からそれを選択したのか）みたいな点を確認なり？してみた方が良いのではなかろうか，とか思いました．なんとなく．
現在自動車系の企業にて、組み込みソフトウェアの作成を行っております。
現在使用しているプログラムでは、列挙型の値を「<」や「>=」を用いて比較を行っている部分があり、違和感を感じております。
列挙型の値の例としては、High, Middle, Lowのような大きさを表す尺度だけではなく、Start, Stop, Stayなどの状態を表すものもあります。
Stop = 0, Stay = 1, Start = 2とすると、「StatusがStopでなければ」という条件を表すブロックとして、
「Status != Stop」ではなく「Status >= Stay」というように表現されており、非常にわかりにくくなっております。
これを改善するように指摘したところ、
「現状の『Status >= Stay』というモデルで動作に問題がないので、これを変更して不具合が混入するというリスクを犯したくない」
という理由で却下されてしまいました。
そのため、「Status >= Stay」という表現に問題があるということを客観的な根拠をもとに主張しようと考えております。
そこで質問なのですが、「Status >= Stay」という表現がMISRA CやCERT C, ISO 26262やJMAABといったガイドラインに引っかかるといったことはあるのでしょうか？
（自分でも軽くチェックしてみたのですが、特に引っかかっているようなところはありませんでした、、）
fanaさん
コメントありがとうございます。
現在「Status >= Stay」といったような記述がされているのは、このような記述にしても問題がないように、Stop, Stay, Startの値を決めているためのようです。
その一方で、当社にはコーディングの当社独自のガイドラインが存在し、それによると上記のような記述は禁止されております。
この当社独自のガイドラインに従って、上記の記述を訂正したいと提言したのですが、担当者が「当社独自のガイドラインはいまいち信用ならない」といい却下されてしまいました。
そのため、世間一般に存在するガイドラインを参照したいと考えた、という流れとなっております。
ちょっと立場や状況が把握できていませんが
一般的にそのようなガイドラインは当該部署や会社全体での取り決めなので
その担当者の「いまいち信用ならない」という発言は
「うちの部長や社長の決めたことや言動はいまいち信用ならない」
と云ってるのと同じという認識あるのでしょうかね？
can110 さん
コメントありがとうございます。
私もそのガイドラインは遵守すべきものと認識しておりましたが、その担当者は「『絶対』ではなく『推奨』のものだろう」といっております。
このガイドラインが「絶対」なのか「推奨」なのかは現在確認中です。
あと
> MISRA CやCERT C, ISO 26262やJMAABといったガイドラインに引っかかるといったことはあるのでしょうか？
という質問に対しては「まずはご自身で各ガイドラインを読んで（調べて）みては？」と回答しかできないかと思います。
まあ過去に同じ疑問を持って調べた人からの回答があるかもしれませんが。
can110 さん
ご指摘ありがとうございます。
MISRA C、その他のガイドラインについては軽くチェックしてみたのですが、特に引っかかっているようなところはありませんでした。
質問文の説明が不足しており、申し訳ございませんでした。
enumではなくて、int とdefineにしろって趣旨なんですか？
enum StateType{Stop = 0, Stay = 1, Start = 2}
ではなく
typedef int StateType;
static const StateType Stop=0;…(略)
列挙型はenumeration (数え上げ) typeのことですから、順序数と解釈することも可能だと思います。Cでは特別なことをしなくても整数式の中でenum値を使うこともできますし (というか列挙型の定義値はint型ですし)。
「startでもstopでもない中間の状態がある」という理由で3値の列挙型を宣言したうえで不等号を使って値の範囲を指定すること自体は、言語の規約とは矛盾しないように思います。
ガイドラインの有無については、調べてみればわかるのでは。
回答するまでの内容でもないのでこちらに書きますが
ログレベル（FATAL, ERROR, …, TRACE）とかだと
ERROR以上（以下）なら～というコードは書かせてほしいですね。
matukeso さん
コメントありがとうございます。
今回言語をCとしたのですが、正確には少し違っており、matlabで作成したプログラムをC言語でコーディングしております。
matlabの列挙型は
classdef Bearing < uint32
enumeration
North (0)
East (90)
South (180)
West (270)
end
end
のようになっております。
参考：<https://jp.mathworks.com/help/matlab/matlab_oop/enumerations.html>
弊社のプログラムは、enumのuint8型となっております。
私自身C言語をあまりわかっておらず、matukesoさんのおっしゃっていることがよくわかりません。
申し訳ございません。
ikedas さん
コメントありがとうございます。
>>順序数と解釈することも可能だと思います。Cでは特別なことをしなくても整数式の中でenum値を使うこともできますし (というか列挙型の定義値はint型ですし)。
確かにそうですね。
それを考えると、私のいうようなガイドラインは存在せず、弊社で決めるほかないということになりますでしょうか。
>>ガイドラインの有無については、調べてみればわかるのでは。
ご指摘ありがとうございます。
私の方でもチェックをしてみましたが、特に引っかかるようなところはありませんでした。
私の調べ方に問題があった可能性もあると考え、今回質問をさせていただきました。
can110 さん
>>ログレベル（FATAL, ERROR, …, TRACE）とかだとERROR以上（以下）なら～というコードは書かせてほしいですね。
FATAL = 0, ERROR = 1, ... , TRACE = 5のようになっているときに、log_level <= ERRORと書きたいような場面があるということですかね。
そういった場面があるのであれば、私のいうようなガイドラインはないと考えてよさそうですね。
ご意見ありがとうございました。
回答2件
0
ベストアンサー
禁止すべきという主張や規約ではありませんが C の列挙型の扱いは型安全が損なわれるなどの指摘が C++ における改善案として出ています。
そして実際に C++ では enum とは別に enum class が導入され、 enum class では明示的な変換なしに列挙子を整数として扱うことは出来なくなりました。 従来の enum が排除されたわけではありませんしその予定もありませんが、列挙型を整数として扱うのが不格好 (なのでそうではない方法が必要) だという意識は存在するという根拠にはなるかもしれません。
投稿2023/10/10 17:06
総合スコア5740
SaitoAtsushi さん
回答ありがとうございます。
"bool goToAlertAndArmWeapons = ( a1 >= ClrYellow ) ; // No longer allowed, with or without scoping ClrYellow"
の部分でしょうか。
非常に参考になる情報をご教示いただきありがとうございました。
こちらの意見をもとに、モデル改善を要求するのは少し難しいかもしれませんが、今後私がコーディング等を行う上での指針とさせていただきます。
0
それはガイドラインがどーこーというわけではなく、個々のメーカのコード規約で決めるもんです
そもそも、C言語での列挙型といっても、単なる整数の別名でしかありません
投稿2023/10/10 08:08
総合スコア88180
y_waiwai さん
ご回答ありがとうございます。
確かにそうかもしれません。
列挙型に対して「>」等を使用していけないのならば、
Low = 0, Middle = 1, High = 2として、"Status > Low"という条件文を使用することもできなくなってしまいますしね、、
> "Status > Low"という条件文
個人的には，そういう条件文をコードの各所に散らばせたくはないなぁ，みたいな感覚がある．
そういう，現在の enum 値の定義に基づいたようなやつは
その enum とセットで提供されるマクロとか関数の中だけに閉じ込めておきたい的な．
fana さん
コメントありがとうございます。
コーディングの際の参考にいたします。
あなたの回答
tips
プレビュー
