6

According to MISRA C++ 2-5-1 we should generally avoid messing up with digraphs. Though, I don't understand why we should also avoid the use of readable words and, or, not etc. to define common operators &&, ||, ...

The issue is even highlighted as "major" issue for Sonar/MISRA:

[Major]     Open    Replace this digraph 'and' by its equivalent '&&'
[Major]     Open    Replace this digraph 'and' by its equivalent '&&'
[Major]     Open    Replace this digraph 'or' by its equivalent '||'    
[Major]     Open    Replace this digraph 'or' by its equivalent '||'    
[Major]     Open    Replace this digraph 'or' by its equivalent '||'

Is the rule also including the human readable digraphs (that are quite different from the cryptic ??=, ??/) for a particular reason or the rule is just too generic? I haven't found any particular risk or side effect at using them, am I wrong?

Summing up

is there a functional reason for this MISRA rule to include also the human readable digraphs? Should I avoid them only to satisfy blindly a code compliance rule or there's some real tricky reason hiding behind?

Alex Gidan
  • 2,619
  • 17
  • 29
  • 2
    Related to [Why are the written versions of logical operators not more widely used?](http://stackoverflow.com/questions/24123640/why-are-the-written-versions-of-logical-operators-not-more-widely-used?lq=1) – Shafik Yaghmour Jun 17 '14 at 15:52
  • 1
    possible duplicate of [|| vs or keywords](http://stackoverflow.com/questions/11874851/vs-or-keywords) – πάντα ῥεῖ Jun 17 '14 at 15:54
  • 1
    Most probably MISRA bans them for compatibility with older code, written prior to the defnition of these. – πάντα ῥεῖ Jun 17 '14 at 15:56
  • @πάνταῥεῖ Pre-standard C++? It sounds exceedingly silly to have such a rule. But it might well be the reason. – juanchopanza Jun 17 '14 at 16:24
  • 3
    `??=` and `??/` are **trigraphs**. `and` etc. are not digraphs. I think the MISRA checker is broken here. – juanchopanza Jun 17 '14 at 16:26
  • @juanchopanza `and` etc. are listed in the same *Alternative tokens* table as e.g. `%:` and `<:`, so you might say that they are digraphs (given that unlike "trigraph," "digraph" is an informal name anyway). – Angew is no longer proud of SO Jun 17 '14 at 16:49
  • @Angew I see `and` et al, plus the digraphs and others in **2.13 Operators and punctuators [lex.operators]**. By this logic, `]` or `(` would be digraphs too. In any case, the MISRA diagnostic is at best misleading. Re. *alternative tokens*, *These include “digraphs” **and** additional reserved words...* (emphasis mine) although it then mentions that they are colloquially called *digraphs*. I can't say I'm impressed! – juanchopanza Jun 17 '14 at 16:52
  • 1
    `and` and `or` are less readable than `&&` and `||` *to experienced C and C++ programmers*. – Keith Thompson Jun 17 '14 at 19:14
  • 1
    I modified the question to be more specific and less opinion based. Please tell me if I can improve it. – Alex Gidan Jun 17 '14 at 20:20
  • I am not sure the question is significantly less opinion based. Personally, I find `and`, `or` etc. perfectly fine and use them interchangeably with their more popular counterparts without even realising. But as you can see, others disagree. I still think the MISRA rule is a poor one. I cannot see what problems could arise in using `and` etc. – juanchopanza Jun 18 '14 at 07:28
  • @KeithThompson Do you have data to back that up? Because I could claim the opposite, based on my experience (which includes all experienced C and C++ programmers I have worked with). – juanchopanza Jun 18 '14 at 07:30
  • 1
    Vote to reopen. The question is not asking "which do you think is most readable", it is asking for a rationale over why a technical industry standard enforces a certain practice. So the question is not opinion-based. It may very well be that the MISRA rationale is based someone's opinion, but that's no fault of the OP. – Lundin Jun 18 '14 at 07:48
  • 1
    I had to do some MISRA compliance work recently and I found the MISRA spec to be very depressing (you could say MISRAble!). So many of the rules were designed to restrict 'hard to understand' code - any decent programmer should know the majority of the language they're using and if they don't, get better programmers or train them up properly. – Skizz Jun 18 '14 at 08:18
  • @Skizz "Hard to understand" is not a black or white case. There are plenty of good MISRA rules aiming to fix things that you cannot reasonably expect every programmer to know. Most notably the various implicit type promotion rules, but also things like operator precedence in needlessly complex expressions. I also believe that one purpose of MISRA is actually to educate programmers about various dangerous practices, or at least forcing them to educate themselves if they want to resolve the static analyser errors. – Lundin Jun 18 '14 at 09:06
  • @juanchopanza: I have no hard data to back that up. Personally, I don't think I've ever seen `and` and `or` used in real-world C++ (or C) code, but that doesn't necessarily mean much. And on the other hand, any experienced C or C++ programmer *should* know what `and` and `or` mean. (C requires `#include ` before using these tokens.) – Keith Thompson Jun 18 '14 at 14:59
  • I would like to be clearer... This is not a matter whether one stylistically prefers the 'or' to the ||. I would like to know if there is a **functional reason** behind this MISRA rule to include also 'and', 'or', 'not'... – Alex Gidan Jun 18 '14 at 23:42
  • @AlexGidan: For what it's worth, I can't think of any functional reason for it. Old C compilers that don't support `and` and `or` are unlikely to be a concern; I haven't studied MISRA C++, but it probably depends on other equally new feature. The only argument for the rule I can think of is familiarity to programmers reading the code. – Keith Thompson Jun 19 '14 at 01:16

1 Answers1

2

Digraphs and Trigraphs are only lexical sugar. The compiler will replace them with other single characters.

MISRA C++ rule 2-3-1 says "Trigraphs shall not be used."

Trigraphs are all characters which start with "??" and a third character which defines, what the trigraph means. (e.g. "??-" is the same as "~")

MISRA C++ 2008 does not enumerate these. So I assume, that all trigraphs are meant. These are:

??= ??/ ??’ ??( ??) ??! ??< ??> ??-

MISRA C++ rule 2-5-1 says "Digraphs shall not be used."

The Digraphs are e.g. "<%" or "%>" (is equal to "{" and "}").

MISRA C++ 2008 enumerates the forbidden ones:

<% %> <: :> %: %:%:

Digraphs and Trigraphs

For me they are relicts from a ancient time. You can write a C++ program e.g. without using any braces. They make source code unreadable:

void a()
<%
    int b<:2:> = <%0, 0%>;
%>

As far as I see, there is no rule in MISRA C++ 2008, that forbids the use of human readable logical operators (although they are very uncommon). This means the Sonar rule is more restrictive than MISRA C++ 2008. I think it is a bug.

In my opinion the C/C++ community isn't familiar with human readable logical operators. So they should be consequently avoided.

BTW: The C++ standard calls them trigraphs and "alternative tokens". The logical opterator alternatives are enumerated there as such.

Stefan Weiser
  • 2,264
  • 16
  • 25
  • 3
    The C++ standards define a set of "alternative tokens", a class which includes your example "digraphs", `%:%:`, and the so-called "human readable logical operators". This leads to the quandary as to whether MISRA's "Digraphs" include all of the C++ standard's "alternative tokens" or only a subset. You seem to assume it only includes the two-character ones, while Sonar seems to assume it also includes `and` and `or`, at the least. If all of the alternative tokens are "digraphs", then `and` can't be used. – Samuel Edwin Ward Jun 28 '14 at 18:49
  • If sonar blames also `and` etc., this is a bug. MISRA do not state them as digraphs or trigraphs. The standard defines them as alternatives for `&&` etc. – Stefan Weiser Jun 29 '14 at 15:36
  • I improved my answer with all conecrete enumerated digraphs and trigraphs. – Stefan Weiser Jun 30 '14 at 03:30
  • @StefanWeiser, can we really state it's a bug in sonar? It looks to me it's just applying the MISRA rule without "thinking too much"... Isn't the rule itself that is wrong? – Alex Gidan Jun 30 '14 at 08:40
  • That's the missing piece of the puzzle. If MISRA has a list defining what they mean by digraphs and these aren't in the list, then they aren't forbidden by this rule. – Samuel Edwin Ward Jun 30 '14 at 20:20
  • @AlexGidan, coding without thinking too much leads very often into bugs, doesn't it? I think it is not only bad, that Sonar states them as a bug, because it is at least very uncommon to use `and` etc. I think, that rule is OK. – Stefan Weiser Jul 01 '14 at 04:12