How does Sonar calculates software metrics particularly LOC and cyclomatic complexity? Does it uses any particular tools? IF yes, please also give the names.
For each supported language, a "squid" plugin is used to parse the source code and determine some base metrics such as LOC and complexity. How the complexity is calculated varies based on the plugin.
For example, here's the source code files for the JavaScript plugin: https://github.com/SonarCommunity/sonar-javascript/tree/master/javascript-squid/src/main/java/org/sonar/javascript/metrics
In this case, the complexity is calculated in the plugin itself using a very simple formula.
And here is the same set of classes for the C# support: https://github.com/SonarCommunity/sonar-dotnet/tree/master/sonar/csharp/sonar-csharp-squid/csharp-squid/src/main/java/com/sonar/csharp/squid/metric
The creation of metrics, though, can be done by any plugin, so you could write your own plugin if you wanted to supplement the data, or display the data in a different way.
Also take a look at the answer to this question (about creating a new plugin) by Fabrice, one of the .Net plugin maintainers: SonarQube - help in creating a new language plugin
You can browse http://docs.codehaus.org/display/SONAR/Metric+definitions for more details.
Related
How can I apply a branching logic for an entire section. At present, I have to do it to individual questions within the section.
If you are on a sufficiently recent version (version 12.0.0, released 2021-11-22), you can employ form display logic; that is, apply branching logic to the display of an entire form.
Prior to its inclusion in the core code, this functionality was provided by an external module called 'form render skip logic'.
Ask your local admin for advice.
I realized redcap does not have an easy way to do this except via exporting the data dictionary and copy pasting the branching logic across all questions of interest then re-importing.
I would like to add a non-standard variant of a language already supported by Stanza. It should be named differently from the standard variety included in the common distribution of Stanza. I could use a modification of the corpus for training the AI, since the changes are mostly morphological rather than syntactical, but how many steps would I need to take in order to make a new language variety for Stanza from this background? I don't understand what data are input and what are output in the process of adding a new language in the web documentation.
It sounds like you are trying to add a different set of processors rather than a whole new language. The difference being that other steps of the pipeline will still work the same, right? NER models, for example.
If that's the case, if you can follow the steps to retrain the current models, you should be able to then replace the input data with your morphological updates.
I suggest filing an issue on github if you encounter difficulties in the process. It will be a lot easier to back & forth there.
Times when we would actually recommend a whole new language are when 1) it's actually a new language or 2) it uses a different character set - think different writing systems for ZH or for Punjabi, if we had any Punjabi models
There must exist some application to do the following, but I am not even sure how to google for it.
The dilemma is that we have to backtrace defects and in doing so this requires to see how certain fields in the output xml have been generated by the XSL. The hard part is spending hours in the XSL and XML trying to figure out where it was even generated. Even debugging is difficult if you are working with multiple XSL transformation and edits as you still need to find out primary keys that get in the specific scenario for that transform.
Is there some software program that could take an XSL and perhaps do one of two things:
Feed it an output field name and it would generate a list of all
the possible criteria that would generate this field so you can figure out which one of a dozen in the XSL meets your criteria, or
Somehow convert the xsl into some more readable if/then type
format (kind of like how you can use Javadoc to produce readable documentation)
You don't say what tools you are currently using. Tools like oXygen and Stylus Studio have some quite sophisticated XSLT debugging capability. OXygen's output mapping tool (see http://www.oxygenxml.com/xml_editor/working_with_xslt_debugger.html#xsltOutputMapping) sounds very like the thing you are asking for.
Using schema-aware stylesheets can greatly ease debugging. At least in the Saxon implementation, if you declare in your stylesheet that you want the output to be valid against a particular schema, then if it isn't, Saxon will tell you what instruction in the stylesheet caused invalid output to be generated. Sometimes it will show you the error at stylesheet compile time, before you even supply a source document. This capability is greatly under-used, in my view. More details here: http://www.stylusstudio.com/schema_aware.html
It's an interesting question. Your suggestions are also interesting but would be quite challenging to develop; I know of no COTS or FOSS solution to either, but here are some thoughts:
Your first possibility is essentially data-flow analysis from
compiler design. I know of no tools that expose this to the user,
but you might ask XSLT processor developers if they have ever
considered externalizing such an analysis in a manner that would be useful to XSLT
developers.
Your second possibility is essentially a documentation generator
against XSLT source. I have actually helped to complete one for a client in
financial services in the past (see Document XSLT Automatically), but the solution was the property of
the client and was never released publicly as far as I know. It
would be possible to recreate such a meta-transformation between
XSLT input and HTML or Docbook output, but it's not simple to do in the
most general case.
There's another approach that you might consider:
Tighten up your interface definition. In your comment, you mention uncertainty as to whether a problem's source is bad data from the sender or a bug in the XSLT. You would be well-served by a stricter interface definition. You could implement this via better typing in XSD, addition of xsd:assertion statements if XSD 1.1 is an option, or adding a Schematron-based interface checking level, which would allow you the full power of XPath-based assertions over the input. Having such an improved and more specific interface definition would help both you and your clients know what should and should not be sent into your systems.
I'm on a project working with SonarQube and the given analysis. Can anyone tell me if I can add an own metric which SonarQube uses to analyse my code? For example (I know this one already exists "Comments Balance"):
Tharmar's Metric 00 = "Commented Lines of Code" / "Lines of Code" - OR -Tharmar's Metric 01 = Count the word "Tharmar" used in "Lines of Code"
I tried to find something usefull in the documentation. But the only thing I found was about Manual Measures. I was able to create a new column within the analysis. (proved with the csv-plugin) Understandably, it contains no data.
Is there a way how I can tell SonarQube how to find that data? Or how to calculate that Metric with the given data.
Thanks for any help :)
Manual measure won't answer your need: they are only used to push "simple" data at project level.
What you need to do is to write your own SonarQube plugin to compute your own metrics. Here's the material that will be useful to you:
Coding a Plugin documentation
Sample Plugin that you can use to bootstrap your plugin. Most notably, check the Sensor and Decorator classes.
I'd like to know what are the most recurrent in a given text or group of text (pulled from a database) in ruby.
Does anyone know what are the best practices?
You might start with statistical natural language processing. Also, you may be able to leverage one or more of the libraries mentioned on the AI Ruby Plugins page.