...any change?
The scenario is this:
For our company we develop a standard how code should look.
This will be the MS full rule set as it looks now.
For some specific projects we may want to turn off specific rules. Simply because for a specific project this is a "known exception". Example? CA1026 - while perfectly ok in most cases, there are 1-2 specific libraries we dont want to change those.
We also want to avoid having a custom rule set. OTOH putting in a suppress attribute on every occurance gets pretty convoluted pretty fast.
Any way to turn off a code analysis warning for a complete assembly without a custom rule set? We rather have that in a specific file (GlobalSuppressions.cs) than in a rule set for maintenance reasons, and to be more explicit ;)
There is no way to create an assembly-level exclusion that will cover all violations of that rule for types and/or members within the assembly.
You could probably still use the CodeAnalysisRules element in your project file, but this is essentially just as much work as a custom ruleset, and more difficult to track given that it's not shown in the project properties UI.
Regardless of the mechanism you would prefer to use, you should also consider whether you want to simply exclude existing violation or whether you want new violations to be introduced. If the former, you should add SuppressMessage attributes for the existing violations. If the latter, you should disable the rule for the assembly.
BTW, in case you weren't aware of this, you can suppress multiple violations at once in the violation list in VStudio.
You'd actually have more flexibility of exclusions with CodeIt.Right for static analysis. And saved all that time :)
Related
We use SonarQube against our application. One of the SonarQube rules says:
Selectors of lower specificity should come before overriding selectors of higher specificity
The details are here. As my application has many violations, changing the order by hand isn't really feasible. I'm wondering if there's a way to use scss-lint, stylelint or something else in a "fix" mode that could change the order of the selectors. I looked but couldn't find anything in stylelint. Maybe it can't safely be done automatically, as changing the order could affect specificity and therefore change the application behaviour...
As I personal! know there is no Linter which provide that. (I am curious about it.) But just some thoughts about the need of following that 'rule':
Indeed: writing SASS/CSS the way Selectors with lower specifity comes first is a good practicse. The CSS structure becomes more readable and it is easier to build up your code structure as there is a clearer systematic in your head (and the code).
But just up from the mechanic CSS works there is REALLY NO NEED to do it this way. The code simply doesn't become safer doing so or less safe and the pages don't load slower not doing it. That is what the mechanic of specifity has been done for: as of the specifity not the order of the selectors counts and you are able to write your code in the order you need it. Only if the specifity is the same the order counts.
So, maybe this rule leads to 'better' code. But: NOT ALL RULES NEEDS TO BE FULLFILLED. Not all rules Google tries to establish with their best practice rules they offer in their browser, nor all rules other analysis tools provide needs to be followed.
And if not in this project as it needs resources to correct it ... it maybe could but has not be a target for next project ;-)
If you have a Transaction with complex rules, it can difficult to 'manage' them logically inside the rules section because the order they execute is most likely not the order in which they appear in the rules. You can turn on Detailed Navigation and see the Evaluation Tree, but I was thinking there could be an improvement in this area.
What if there was a model Preference or object Preference that you could set that would, after specification, reorder the rules in the code to match the Evaluation tree? There could be some clear comments about when things happen, and I would be fine with seeing these 'timing comments' with nothing in them so I knew when rules would fire and when they would not.
We use a Pattern for our KBs and manipulation of rules, events, etc, is already happening, so in this case those would not be changed. But the manually added rules (outside the pattern's rules) could be reordered.
Also, if the 'timing comments' are inserted, this could be helpful for developers in exposing the time slots that are available instead of having to refer to the wiki repeatedly.
Is this a good idea?
I don't think so. There are almost two reasons for that, the first one is technical: GeneXus executes the rules "in order" (how they were placed in rules) when they match the triggering criteria. So, maybe reordening the rules will produce unexpected behaviour in your application. You could argue that GeneXus would let those rules where they were placed, but, it is still dangerous.
The second one has to do with our "way of programming". I put a lot of comments in the code, I like comments, even in the rules. If GeneXus reorders the rules, how do it knows which comments belongs to which rule. At least for me, I don't like that a "tool" reorganize/reorder my code. And I bet I'm not the only one.
I'm creating code for interfaces specified in IBM Rational Rhapsody. Rhapsody implicitly generates include statements for other data types used in my interfaces. But I would like to have more control over the include statements, so I specify them explicitly as text elements in the source artifacts of the component. Therefore I would like to prevent Rhapsody from generating the include statements itself. Is this possible?
If this can be done, it is mostly likely with Properties. In the feature box click on properties and filter by 'include' to see some likely candidates. Not all of the properties have descriptions of what exactly they do so good luck.
EDIT:
I spent some time looking through the properties as well an could not find any to get what you want. It seems likely you cannot do this with the basic version of Rhapsody. IBM does license an add-on to customize the code generation, called Rules Composer (I think); this would almost certainly allow you to customize the includes but at quite a cost.
There are two other possible approaches. Depending on how you are customizing the include statements you may be able to write a simple shell script, perhaps using sed, and then just run that script to update your code every time Rhapsody generates it.
The other approach would be to use the Rhapsody API to create a plugin/tool that iterates through all the interfaces and changes the source artifacts accordingly. I have not tried this method myself but I know my coworkers have used the API to do similar things.
Finally I found the properties that let Rhapsody produce the required output: GenerateImplicitDependencies for several elements and GenerateDeclarationDependency for Type elements. Disabling these will avoid the generation of implicit include statements.
Is it possible to write your own gnatcheck rules, and if so, can someone point me to a good reference? I am searching for a particular "style" that is being used, and would love if I could simply write a rule that says if you see said style, it will throw up a warning, or an error, this way we can flag when this isn't following a particular standard.
A bit of background may be helpful here. While the style checks hold out a lot of promise for enforcing user style guidelines, that isn't exactly what they are for.
The main purpose of those checks is to enforce Ada Core's (The folks who maintain the compiler) style on the sources of the Ada compiler itself. You may notice that the checks get automatically turned on if you try compiling one of the compiler's own source files.
It doesn't really serve AdaCore's purposes at all if the styles enforced by the checks themselves are user-configurable, so they added no feature like that.
Your first option if you want to use it yourself is to just stick to AdaCore's coding style. I haven't found it horrible in the past, so you may just look at doing that.
Still, making some kind of configurability would be a really cool feature for somebody to add. If you go this route, you probably would have to make it configurable (with the current behavior as the default), rather than just changing the checks. The reason is that you'd have to modify the compiler sources to accomplish this, and as I mentioned above, the compiler turns the checks on when compiling itself. You really don't want to have to reformat a ton of working Gnat compiler source files.
I'd really like to see someone do this at some point, as it would make the checks much more useful to those of us who work for someone besides AdaCore.
In addition to trashgod's reference, I think Section 7.1 of this PDF might be of some help:
http://extranet.eu.adacore.com/articles/HighIntegrityAda.pdf
For reference, the existing GNAT style checking is described in the GNAT User's Guide under ยง3.2.5 Style Checking. As the rules are enforced by the compiler, additional rules would require corresponding modifications.
Try as I might to keep [SuppressMessage]s to a minimum in the codebase, new ones continue to get introduced. I would like some way to say in the code "I've reviewed this [SuppressMessage] and it is 'acceptable'".
One thought was to create my own My.CodeAnalysis.SuppressMessageAttribute class which inherits from System.Diagnostics.CodeAnalysis.SuppressMessageAttribute, but that class is sealed.
I'm sure I could cobble together something with a comment near the attribute and a post-processing step, but I'd like to stick to what is available "in the box" with Visual Studio 2010.
Even if the attribute weren't sealed, a subclassing approach would not work since the code analysis engine screens for exact SuppressMessageAttribute instances. As current versions are written, the engine would completely ignore subclass instances.
Personally, I use the following approach for management of suppressions:
All "permanent" suppressions must
have a Justification property that
explains the reason for the
suppression.
Where possible, permanent
suppressions must be placed in the
target code file. Otherwise, they
must be placed at the top of the
GlobalSuppressions file.
Temporary suppressions must all be
placed below a "Temporary
suppressions" header comment in the
GlobalSuppressions file, and they
should not be assigned a
justification.
All permanent suppressions are
subject to code review, in exactly
the same manner as the code itself.
I use difference detection to flag
code for review, so I can see which
suppressions have been added or
changed just as easily as I can see
which code has been modified.
Temporary suppressions must all be removed by a pre-defined phase of the project. After this point has passed, a rule that detects missing Justification properties is enabled.
If this sort of thing wouldn't work for you, another approach would be to use stand-alone FxCop to annotate your suppressed violations. Unfortunately, these annotations would reside outside your code base, but maybe that would suit you better if you want to prevent developers from "blessing" their own suppressions.
When you right-click on the CA warning in the errors list, one of the options given is Suppress Message(s) -> In Project Suppression File. When you select that, Visual Studio will add a line like the following to a GlobalSuppressions.cs file in your project:
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1704:IdentifiersShouldBeSpelledCorrectly", MessageId = "Autofac")]
This keeps them grouped together and out of your code files. Is this what you are trying to get at?