...

Quality Reviewer can share the results in anonymous way using Blockchain, under permission of the User. 

Existing electronic Quality systems, like QSM and ISBSG, all suffer from a serious design flaw: they are proprietary, that is, centralized by design, meaning there is a single supplier that controls the code base, the database, and the system outputs and supplies the browsing tools at the same time. The lack of an open-source, independently verifiable output makes it difficult for such centralized systems to acquire the trustworthiness required by enterprises and quality standard makers. The blockchain works as a secure transaction database, to log the audit quality results in a trustworthy way. The results are classified by Industry, Application Types and Size.

The software metrics data available on Blockchain can be used to assist you with:

...

Supported Programming Languages: C#, Vb.NET, VB6, ASP, ASPX, JAVA, JSP, JavaScript, TypeScript, Java Server Faces, Ruby, Python, R, GO, Kotlin, eScript, Apex, Shell, PowerShell, LUA, HTML5, XML, XPath, C, C++, PHP, SCALA, Rust, IBM Stream Programming Language, Objective-C, Objective-C++, SWIFT, COBOL, ABAP, SAP-HANA, PL/SQL, T/SQL, Teradata SQL, SAS-SQL, ANSI SQL, IBM DB2, IBM Informix, MySQL, FireBird, PostGreSQL, SQLite.

Comparison Analysis 

Comparing metrics helps us visualize a pattern and trend of the data and subsequently the code which exhibits these qualities.

WMC vs DIT

Comparing Weighted Method Complexity (WMC) with Inheritance depth of a class (DIT), gives us a fact that with increasing inheritance depth the complexity decreases, i.e, the complexity of classes are well distributed. In a system where there is very little use of inheritance the complexity of classes are concentrated and lead to more Blob classes and Speculative Generality classes. It is also easy to find extreme cases or deviating elements.

...

Cyclomatic vs Essential Complexity

The following McCabe®Scatterplot graph is also provided:

...

Abstractness vs Instability

The idea behind this graph is that the more a code element of a program is popular, the more it should be abstract. Or in other words, avoid depending too much directly on implementations, depend on abstractions instead. By popular code element I mean a project ﴾but the idea works also for packages and types﴿ that is massively used by other projects of the program. It is not a good idea to have concrete types very popular in your code base. This provokes some Zones of Pains in your program, where changing the implementations can potentially affect a large portion of the program. And implementations are known to evolve more often than abstractions. The main sequence line ﴾dotted﴿ in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line – on the other hand, if it’s degree of abstraction is low, it is positioned in an area that is called the “Zone of Pain, else when the degree of abstraction is high, it is located in the “Zone of Uselessness”.

...

Peer and Descendant Comparison

Thresholds or acceptable value range of software metrics are often debated, but it is not to be a reason to opt out. Application/Program specific threshold can be used to evaluate code quality at the first level, however to find a perfect threshold/justification for a metric involves deeper analysis on the values specific to the project. Quality Reviewer provides a feature to understand an object's measurement compared to their peers. For example comparing a Class complexity vs. its peers in the project gives a justification for its value/state. In addition, to make a judgment about the Class, one has to understand the complexity of its Methods (Composition). Comparing metrics for a method vs. all the methods of a class gives its relative rank, in order to assign importance to that method. Apart from other uses of this comparison, it can be used to categorize metric distribution in "Distribution Analysis", as the metrics view gives the Minimum, Maximum and Average value of a metric in the project one could adjust the categorization to fit the project. This methodology has to be excised with caution as the categorization could become too much project specific and its generalness could be lost.

...

Distribution Analysis 

Visualizing distribution helps to categorize elements based on value range. Quality Reviewer provides a customizable categorization interface to quickly evaluate the distribution. For example distribution of Maintainability Index metric can be categorized into "Very Poor Maintainability", "Poor Maintainability", "Good Maintainability" and "Excellent Maintainability" based on value range. Categorization helps to address issues specifically and on a reduced set of similar elements.

Comparison, Distribution and Custom Analysis are visualized using graphs/charts. While the graphs are abstract representation of data (metrics), we often need to trace back to the resource whose data is being displayed. Quality Reviewer provides a feature to list the resources of a graph elements (categories/individual) and assists further to locate the resource in the project. This View provides an interface which is sensitive to selection in the graphs.

...

COPYRIGHT (C) 2014-2022 SECURITY REVIEWER SRL. ALL RIGHTS RESERVED.