ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

* Mark enum "XXX" with "Flags" attribute or remove this bitwise operation.
* Remove this bitwise operation; the enum "XXX" is not marked with "Flags" attribute.


'''
== Comments And Links
(visible only on this page)

=== on 9 Jul 2015, 15:46:00 Ann Campbell wrote:
\[~tamas.vajk] I know that as written this rule doesn't cover _BitwiseOperatorOnEnumWithoutFlags_ but IMO it obviates it. According to http://stackoverflow.com/a/8480/2662707[SO] the `[Flags]` doesn't actually get you anything w/r/t bitwise usage. What's important is the assigned values.


I propose a Minor followup rule to make sure that `[Flags]` is applied when the enum values are power-of-2.


WDYT?

=== on 10 Jul 2015, 09:41:50 Tamas Vajk wrote:
\[~ann.campbell.2] I've modified slightly the messages and the sample code. I think now it covers your proposed follow-up rule as well.

=== on 10 Jul 2015, 11:14:07 Ann Campbell wrote:
Thanks [~tamas.vajk]

=== on 1 Sep 2015, 07:02:18 Dinesh Bolkensteyn wrote:
IMO it should be another rule (a MINOR one) that suggests to mark power-of-two Enums with `Flags` - that knowledge cannot just sneak into this rule's issue message [~ann.campbell.2].

=== on 1 Sep 2015, 14:21:41 Ann Campbell wrote:
That's between you [~tamas.vajk], [~dinesh.bolkensteyn].

=== on 2 Sep 2015, 12:20:36 Tamas Vajk wrote:
\[~ann.campbell.2] We discussed it with [~dinesh.bolkensteyn] and he convinced me that we should have a minor severity rule that proposes to use the `[Flags]` whenever an enum only contains power-of-two items. (We can't merge that one into this issue, because of the different severity, but has a value, because it improves the understability of the code)

=== on 2 Sep 2015, 15:22:59 Tamas Vajk wrote:
\[~ann.campbell.2] We realized during the implementation that this power-of-two enum value restriction can't be enforced, because

----
enum Permission
{
  None = 0,
  Read = 1,
  Write = 2,
  ReadWrite = Read  | Write, //means 3
  Execute = 4
}
----
is totally valid. So there is no need for the other RSPEC which we discussed above. I'll change this one.

=== on 2 Sep 2015, 15:24:59 Tamas Vajk wrote:
\[~dinesh.bolkensteyn] could you please review this rspec? Thanks

=== on 19 Oct 2015, 12:55:44 Tamas Vajk wrote:
This RSPEC is closed, as we realized during the implementation that this power-of-two enum value restriction can't be enforced.

=== on 3 Dec 2015, 09:32:15 Tamas Vajk wrote:
\[~ann.campbell.2] I reopened this RSPEC. I'm going through the R# rules, and I think it would still make sense. Note that the rule was closed because we realized that flags enums can't be forced to have only power of two values. So I removed that part, and only left the bitwise operation part in the rule. WDYT?

=== on 4 Dec 2015, 18:40:13 Ann Campbell wrote:
\[~tamas.vajk] I moved the Noncompliant marker in the Noncompliant Code Example.

=== on 7 Dec 2015, 15:59:08 Tamas Vajk wrote:
\[~ann.campbell.2] I see the point of marking the declaration noncompliant, but from a user perspective it would be better on the call:

Let's say we mark the `enum` noncompliant, and say that it should not be used as flags, if it's not marked with `[Flags]`. But the developer would need some verification that indeed it's used somewhere in a binary or/and. So we would probably include a filename and line number in the issue message. And then the dev could go check it there, and then come back to the declaration and fix it.


While in the other case if the usage is marked, the dev would only need to go to the definition, which is just one shortcut away.


What do you think?

=== on 7 Dec 2015, 16:17:37 Ann Campbell wrote:
If we're going to do that [~tamas.vajk], then we need to flip the rule around: "Non-flags enums should not be used in bitwise operations" (note double-negative).

endif::env-github,rspecator-view[]