SonarCloud analysis for Flux

In general, we don’t use the .Net serialization mechanisms directly in our code. However, any Custom Exception types we implement need to implement ISerializable if they are to be correctly marshalled across app-domains. This will become more important if we build some WebServices that use the Flux API. See Custom Exceptions for an implementation pattern.

This happens about 150 times in the code. After analysis, I found a few places where the performance might be improved. But mostly we are using this to return small collections (like the set of installed tool catalogs etc) that have a few dozen members at most.

Besides, half of these issues happen in the Flux.API where this would be a breaking change. For now, I have turned this off, and we might re-enable later and selectively fix only the cases in Flux.Core, and leave the Flux.API intact.

Code marked with [Obsolete] should be removed - we use this mainly in Flux.API to clients of the API a heads-up before removing some methods / properties. However, we want to give them a 6-month grace time for removal, during which this code-smell would be annoying. So I turned this off.

Usages of the [Obsolete] attribute in Flux.API are each tagged with a remove-by date, so we can periodically (say once a month) revisit them and remove those that have finished their 6-month warning cycle.

There are a lot of places where we use static fields to store UI state (like whether a collapsible section is open or not, the position of a particular editing panel on the screen etc). This state is also sometimes persisted across sessions (by the Flux PStatic mechanism). Such UI code is inherently single threaded, and the danger of updating the same static from different locations does not arise. So this rule should be turned off.

Disagree. Sometimes, a goto statement is the cleanest way to write the code.

Disagree.

Sometimes, a single if statement with a lot of clauses merged with && is more complicated to read and parse than a pair of nested if statements:

This is used a lot in Flux to implement a singleton pattern. For example, since there is exactly one instance of the Flux.Application class, the constructor of Flux.Application does an assignment to the static Flux.Application.It field:

This is a common and well established pattern we use in many places. This is SonarCloud being too paranoid.

There are situations where we like to use this kind of write-only property in Flux.