We have Sonar running on the nightly build, I'm starting tweaking it to satisfy our needs. Currently there many violations on deprecated classes (this classes are no longer maintained, intended to be deleted soon).
What I want to do is to run Sonar on supported classes, i.e. all classes but deprecated.
To have a cleaner issues report.
Is that possible?
Yes you can use the sonar.exclusions property to tell SonarQube which classes to exclude from analysis. Here's a link that you might also find useful
Narrowing the focus of analysis
Related
Not looking for any recommendations, just an objective assessment if any JavaScript framework can be type-checked with Flow in the current state.
With Flow decreasing in popularity compared to TypeScript, framework declaration files tend to be written in TypeScript, and conversion is not trivial nor automatic. Is there still a framework that works well with Flow type inference, or for which you can write your own framework declarations on the fly? Or is Flow mostly used for framework-agnostic business logic today?
So the main one is react, given that its type defs are built directly into the flow project. The other which I haven't looked into personally is Vue, given that it's written in flowtype. But I cannot confirm how to get their type defs as I haven't used it personally.
But even if a library doesn't ship with type defs, it doesn't mean it doesn't support flow. One clear example is styled-components, it's built in flow with first class flow support but do not ship out of the box. Instead their defs are shipped via flow-typed. I'm not sure what their reasoning is, but most likely it's to remove coupling of flow version with styled-component version, and consumers can upgrade each independently.
Overall if you can't find a lib def readily, either not many people use it with flow or the consumers don't bother and just use the types as any. Since there are many projects in the world that don't use any static type checker, having partial static analysis may be good enough.
Answering my own question, I think looking into the flow-typed repo and look for a particular lib or framework will answer this. No recent update = no support, unless you have time and interest to make a PR yourself.
https://github.com/flow-typed/flow-typed
Have a question, never used roslyn before so i'm wondering about maybe experimenting it in a task that i would normally use reflection.
I'm given an external dll, i need to go over some classes in that dll and extract some metadata on them.
Like for example, the class name, property names and types and such.
I would normally use reflection to do it. Should be a super simple task.
But i've been told that this can be achieved using roslyn.
Can it? From what i'm seeing, Roslyn can parse a class but i need to give it the code that represents this calss as text. How would i get the code as text in an already complied code?
Is that even a reasonable scenario to use roslyn? Does it worth the effort?
Thanx!
If all you need is information that's already easily available via reflection, then Roslyn is likely to make it much harder. There's quite a lot of setup required, which can be error-prone and brittle in the face of new releases, in my experience.
I would typically use reflection for anything where the starting point is an assembly. When the starting point is source code, that's when it makes more sense to use Roslyn.
When Roslyn is the right tool for the job, it's amazing - but it doesn't sound like that's the case here.
When you using Roslyn, you have lexical info and symbolic info.
The lexical info won't help you, you must use the symbolic info, for that, you must have compilation and you can create it for compiled code.
With the compilation, you indeed can achieve types info but not runtime info. Anyway, using reflection for this is much straight forward.
When your mission is related to tree transverse or syntax rewriting, Roslyn is perfect, but for metadata info, it's the wrong usage.
It depends on your specific needs but maybe there are other "tools" that more suitable for your task (e.g. cecil or dnlib)
I've got a procedure within a SPARK module that calls the standard Ada-Text_IO.Put_Line.
During proving I get the following warning warning: no Global contract available for "Put_Line".
I do already know how to add the respective data dependency contract to procedures and functions written by myself but how do I add them to a procedures / functions written by others where I can't edit the source files?
I looked through sections 5.2 and 7.4 of the Adacore SPARK 2014 user's guide but didn't found an example with a solution to my problem.
This means that the analyzer cannot "see" whether global variables might be affected when this function is called. It therefore assumes this call is not modifying anything (otherwise all other proofs could be refuted immediately). This is likely a valid assumption for your specific example, but it might not be valid on an embedded system, where a custom implementation of Put_Line might do anything.
There are two ways to convey the missing information:
verifier can examine the source code of the function. Then it can try to generate global contracts itself.
global contracts are specified explicitly, see RM 6.1.4 (http://docs.adacore.com/spark2014-docs/html/lrm/subprograms.html#global-aspects)
In this case, the procedure you are calling is part of the run-time system (RTS), and therefore the source is not visible, and you probably cannot/should not change it.
What to do in practice?
Suppressing warnings is almost never a good idea, especially not when you are working on something safety-critical. Usually the code has to be changed until the warning goes away, or some justification process has to start.
If you are serious about the analysis results, I recommend to not use such subprograms. If you really need output there, either write your own procedure that replaces the RTS subprogram, or ensure that the subprogram really has no side effects. This is further backed up by what Frédéric has linked: Even if the callee has no side effects, you don't know whether it raises an exception for specific inputs (e.g., very long strings).
If you are not so serious about the results, then you can consider this specific one as a warning that you could live with.
Wrapper packages for use in development of SPARK applications may be found here:
https://github.com/joakim-strandberg/aida_2012
I think you just can't add Spark contracts on code you don't own, especially code from the Ada standard.
About Text_Io, I found something that may be valuable to you in the reference manual.
EDIT
Another solution compared to what Martin said, according to "Building high integrity applications with Spark" book, is to create a wrapper package.
As Spark requires you to deal with Spark packages but allows you to depend on a Spark spec with an Ada body, the solution is to build a Spark package wrapping your Ada.Text_io calls.
It might be tedious as you will have to wrap possible exceptions, possibly define specific types and so on but this way, you'll be able to discharge VCs on your full Spark package.
I have spent a day migrating all PMD and Checkstyle rules to the new Squid rules, as the PMD/Checkstyle ones are marked as deprecated.
However, some fine tuning options which I am used to with PMD/CS, are not present in Squid.
As a result, Sonar is cluttered with thousands of issues which reports nothing of real value.
Example 1
Rule:
BadConstantName_S00115_Check / S00115
All our enums are implemented with camelCase instead of CONSTANT_NAME, e.g.:
public enum Classification {
PoorMinus(1),
Poor(2),
PoorPlus(3),
OrdinaryMinus(4),
Ordinary(5),
is easier to read than:
public enum Classification {
POOR_MINUS(1),
POOR(2),
POOR_PLUS(3),
This is done to improve readability when referenced elsewhere in the code (using static imports)
So what I am looking for is a way to suppress this rule for enums, as we want to keep the rule for "real" constants.
Example 2
Rule:
MethodCyclomaticComplexity
After migrating this rule reports complexity for all equals and hashcode methods.
(the deprecated CS rule was easy to suppress for these methods)
It makes no sense (at least for us) to measure complexity of methods which are auto-generated by Eclipse/IntelliJ. What is important is to measure complexity on the "business logic" part of the code
Here we would really like to suppress the rule for these/specific methods
Example 3
Rule: UndocumentedApi
I want to ensure javadoc for interfaces (including class and methods) and classes at class level only (not methods/fields).
As it is now, this is not possible.
Again, I would like to disable checking for methods and fields
CHALLENGE
Does anybody know how to achieve these kind of suppression?
I have looked at Settings / Exclusions on SonarQube, however it seems very hard or even impossible to achieve this with the exclusions settings.
So what we really need is to be able to tweak rules to suppress checking of certain types and methods, to make the rules more flexible.
Ideally this should be implemented as a general features, which can be easily applied to rules where this makes sense.
As for now I have to disable these rules (and most likely others as well), because the configuration of the rules are not fine-grained.
Where can I submit this as a feature request?
I have checked out the source from Github, so currently looking into programmatically fixing these issues. This is however not a viable long-term solution.
Dag is correct, these rules have no configurations. After internal discussions at SonarSource, configuratons are not going to be added.
The best idea for your situation would be to implement custom rules in Java as discussed here
I have seen similar need on other rules too, but i guess the new philosophy is something else:
http://www.sonarqube.org/already-158-checkstyle-and-pmd-rules-deprecated-by-sonarqube-java-rules/
Too many configuration options: in a perfect world, a good quality rule is a rule WITHOUT any configuration options.
PS: Somehow i don't feel comfortable with the very long term ambition of making PMD, Checkstyle and Findbugs obsolete via SonarQubes own rule engine, but this is just my opinion.
Especially for PMD the way isn't that long. Support for PMD 5 doesn't seem to come and SonarQube 4.2 does not even have the pmd-plugin by default.
When jQuery, Microsoft or some other software company says:"this function is deprecated".
For example, when there is a func1 that works fine in version 1.0 and is deprecated in version 2.0 that also introduces a new func2:
Should func1 also be included in version 2.0 for backwards compatibility?
Is func1 supposed to work without bugs in version 2.0? ( func2 is fine with versions 2 and 1)
Is func2 allowed not to work correctly in version 2.0?
What does deprecation really mean and does it mean the same in all organizations?
For ex. the live method in jQuery doesn't work in 1.7 in IE but it does in Chrome).
I think the Wikipedia-article on Deprecation answers this one pretty well:
In the process of authoring computer software, its standards or documentation, deprecation is a status applied to software features to indicate that they should be avoided, typically because they have been superseded. Although deprecated features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated—rather than immediately removed—in order to provide backward compatibility, and give programmers who have used the feature time to bring their code into compliance with the new standard.
Deprecated means they don't recommend using it, and that it isn't undergoing further development. But it should not work differently than it did in a previous version unless documentation explicitly states that.
Yes, otherwise it wouldn't be called "deprecated"
Unless stated otherwise in docs, it should be the same as before
No, but if there were problems in v1 they aren't about to fix them
If there are true answers to those questions, it would be different per software vendor and would be defined by the vendor. I don't know of any true industry standards that are followed with regards to this matter.
Historically with Microsoft, they'll mark something as deprecated and state they'll remove it in a future version. That can be several versions before they actually get rid of it though.
Deprecated in general means "don't use it".
A deprecated function may or may not work, but it is not guaranteed to work.
The simplest answer to the meaning of deprecated when used to describe software APIs is:
Stop using APIs marked as deprecated!
They will go away in a future release!!
Start using the new versions ASAP!!!