MISRA new rule suggestion

I think it would be better to disallow two identifiers whose only difference is by underscores, just like it's a bad idea to have separate identifiers distinguished only by small or capital letters. Thus "time_left" would be fine, as long as you don't also have a "TimeLeft", just as having "TimeLeft" and "timeLeft" would be a bad idea.

"under-under-loop"

"time-under-left"

-- Dave Tweed

Following Mr pre-decremented Tweed's suggestion, I am going to have to start using the following

_Milkwood _score _pass _pants

Ian

..well as _ is often called an "Underscore", that one could causeeven more confusion....

Captain Over, Captain Under, Captain Done?

(apologise to Airplane part Deaux :-)

In article , Rob writes

I will show the MISRA-C team tomorrow. We are half way through one of our 2 day meetings.... We need a diversion at tea time :-)

Having variable names such as L00P, LO0P are much more of a problem than an underscore. Varaibles starting with an underscore should not be used in user apps in anycase. They are supposed to be for the compiler implementor.

Regards Anton Erasmus

It's just you.

Actually, I think most of MISRA (and most other coding "standards") could be replaced with one simple rule: "Lint your d*mn code."

Regards,

-=Dave

Is that lint it using the MISRA-C conformance filter?

You're not. It is an identifier reserved for the implementor. If you are trying to use it you are wrong.

If your lint policy says so. Otherwise, no.

FWIW, I've been using PC-lint from Gimpel for almost 20 years. It has saved my posterior more times than I care to count (or admit).

I've been using (required to use on selected projects) the MISRA-bull guidelines (V1 -- I haven't seen V2 yet) for about 4 years. The only thing it's saved me is attempting to explain to the customer why it's unnecessary -- They can just check off the MISRA box on their list and go away happy.

Regards,

-=Dave

I would say it's just you, because you really want to pronounce all of those things "time left", but none of them are actually spelled that way.

I suppose you could pronounce "TimeLeft" by runningthewords together, to make it clear that it was a run-together word. But that doesn't tell you whether it's timeLeft, TimeLeft, or some other random spelling. And you could pronounce "__loop" as "double-under loop", but then I wonder how you are going to pronounce "__double_under_loop". And you could combine them: "__DOUBLE_Underloop". There's no easy way to pronounce those. In some languages, programmers do use all those different conventions at once. What a mess!

The programming language that I usually work in (Lisp) uses a different set of conventions. First of all, case doesn't matter. If you say "UNDER" or "under" it means the same thing, so we don't bother with run-together words and worrying about the case.

And although you could use underscore, nobody does, because we can use dash ("-"), which reads more naturally. I make this claim, because nobody is ever instructed not to use underscore. They know that they could, and many of the older programmers came from languages (like PL/I) where that's you always did. And yet nobody --- in particular, no newbies -- ever even suggest using underscores. I think the only reason this is not done in other languages is the infix subtraction problem.

So we would always just write "time-left", pronounced "time left".

Having seen other replies, I wonder whether some people think of rules in isolation.

Makes basic assumption that all people only create variables using English to describe the function/variable/constant.....

That is a different issue to you underscores example which if anything is a rule of making each name not having minor variations due to case or single punctuation characters.

Probably just you, as I particular hate groupings like the following

LeftHandedWidgetCount LeftHandedWidgetCountMax LeftHandedWidgetCountMin LeftHandedWidgetCountStep LeftFootedWidgetCount LeftFootedWidgetCountMax LeftFootedWidgetCountMin LeftFootedWidgetCountStep LeftFootedWalkingCount LeftFootedWalkingCountMax LeftFootedWalkingCountMin LeftFootedWalkingCountStep

Which when combined in complex statements make following the flow prone to errors of auto assumption when reading. Having seen some code that because the compiler can support long names you end up with very long names because you can.

This is like phone numbers, there comes a point where it is difficult to remember all the long sequences when the sequences get too long.

In article , Dave Hansen writes

Me too.

V2 is 141 rules. A complete re-write, re-organise and re-number.

Whilst it is not perfect a lot of people who know what they are doing seem to rate it.

MISRA C rules sound like common sense when you have been through tricky bugs, We try to follow them as far as possible.

lint is ok but it is not a bad idea to have coding rules in order to plan your coding in advance. lint helps to ensure you did it right.

Is that a cultural problem ? In this case it is beyond hope;)

I once saw a sound advice, that you use the long names for globals and the short names for locals.

Something like for(CounterOfLeftHandedWidget=0; ...) is overkill. for (ct_lhw=0; ...) is easier to read. You don't get lost in noise. If you have only a few local variables in your function it is not necessary to have long names.

Globals? What globals? (I avoid global variables at all costs. I'm hoping you mean function names.)

I dislike cryptic variable names (e.g. ct_lhw) intensely. Common sense would suggest a compromise, e.g. WidgetCountLH.

Steve

... snip ...

I seem to be one of the very few who agree with you. I think it is a consequence of extreme laziness, and thus reluctance to use the shift key.

-- Some informative links: news:news.announce.newusers

In a situation like that, one should also check the (implementation-specific) significant initial character length. In the examples above, if the compiler only recognizes the first 16 characters, then LeftHandedWidgetCount and LeftHandedWidgetCountMax refer to the same variable.

This _definitively_ makes sense in situations when telephone support is given. Typical situations would be when someone is instructed over the phone to enter some command line interpreter commands. In such situation it would be quite catastrophic, if the command or parameters would include underscores, hyphens or be case sensitive and the command would contain mixed case characters.

On the other hand, how common would it be to dictate for instance a C-program over the phone ?

Even if a small change is dictated over the phone, the receiver could check out the previous use or declaration of that name and apply it.

Even if the dictation would contain a declaration of a new local variable, the receiver could still use any case/underscore combination at his/her discretion as long as the declaration and use is the same.

Paul