Source code quality is an essential feature for software performance. Ideally, when the software is used, users should feel that it operates eficiently, ensuring that functional and non-functional requirements are met. This work discusses using metrics and attributes to evaluate software code quality, focusing primarily on objectoriented programming for academic projects. We describe the proposed software architecture designed to generate inspections for Python and Java projects and present the quality results.
Object-oriented programming (OOP) has been a fundamental paradigm in software development for
many years. Its origins trace back to the 1960s when the creation of Simula was widely regarded as
the first object-oriented programming language. Developed in Norway by Ole-Johan Dahl and Kristen
Nygaard at the Norwegian Computing Center, Simula was initially designed as a simulation language
to model complex systems. However, it introduced key concepts that would later become foundational
to OOP, such as classes, objects, inheritance, and dynamic binding [
These innovations provided a new way of thinking about programming by organizing code around "objects" that represent both data and behavior, rather than merely focusing on procedures or functions. The introduction of classes allowed for the creation of reusable code structures, and inheritance enabled the extension of existing classes to create new functionality without duplicating code. Simula’s impact extended beyond simulations, as its principles became the basis for more widespread adoption of OOP in other areas of software development.
The influence of Simula as the precursor of OOP can be seen in many modern programming languages,
including Java, C++, and Python. These languages are commonly used to develop robust applications and
continue to be a relevant topic of study due to the emergence of new devices with specific requirements.
Modern applications must adapt to varying screen sizes, processing speeds, and new communication
methods for new devices, such as smart TVs, wearables, and virtual reality glasses. Additionally,
integrating artificial intelligence models in software and hardware for training, validation, and testing
processes requires applying OOP concepts to improve code readability, which is crucial in deep learning.
As we saw before OOP has helped to improve the quality of software, for example, attributes like
maintainability and readability, becoming more critical as large development teams are tasked with
building and evolving software in a rapidly changing environment [
Considering software quality, issues related to code have been widely discussed. Authors like Martin
Fowler introduced the concept of "code smells," which help identify underlying problems that impact
code execution and quality [
New programming languages such as Golang, Scala, Rust, Kotlin, and Swift, have been born to support object-oriented programming. The diversity in syntax and compilation methods across these languages presents a challenge for existing OOP metrics, requiring adaptations to validate the quality of code written in these languages.
Innovations in measuring attributes such as performance have been achieved thanks to the use of
machine learning. For example in this study [
In the academic context, there is a growing efort to enhance the learning of OOP by providing tools
for both students and lecturers. Rubrics for student evaluation often rely on predefined metrics and
tools that detect OOP issues are sometimes used. Feedback plays a critical role in enabling students
to learn from their mistakes and improve over time. Understanding the relationship between code
smells and quality attributes can improve the feedback provided to lecturers. Additionally, metrics help
students avoid common mistakes and improve the overall quality of their applications [
In summary, this study aims to contribute to the evolving field of object-oriented programming by proposing a system to measure metrics that address the unique challenges posed by emerging technologies in the domain of the academy. Our approach leverages the metrics established in previous studies and established OOP metrics to provide a comprehensive framework for evaluating software quality.
This paper is structured as follows: Section 2 presents the concepts and terms for the metrics and attributes of software quality. Section 3 presents the other’s works. Section 4 shows the new proposal system to generate inspections for Java and Python. Section 5 presents the next work. Section 6 concludes the paper.
The definition of metrics in software quality derives from a variety of sources, including documentation
from researchers and companies that have developed approaches to assess software quality [
Software is generally written to solve specific problems, based on a list of requirements. The number of lines of code and its complexity vary depending on factors such as the programming paradigm, language, and operations needed to produce the desired results. Moreover, problems can often be approached in several ways, leading to diferent implementation variations, which complicates the evaluation of software quality.
To address this challenge, several evaluation methods are employed currently to assess code quality: • Testing. This can include unit tests, integration tests, and acceptance tests. • Code Review. A collaborative evaluation by a team to ensure code quality.
• Static Code Analysis. The use of tools to analyze and generate a score for the code. Metrics for software quality can generally be classified into two main categories: 1. Code execution. Related to issues like code smells that can afect runtime performance and behavior. Category Bloasters Object-Orientation Abusers Change Preventers Disposables Couplers Encapsulators
Meaning Code that has grown too large and complex, making it dificult to maintain.
Code that violates object-oriented principles, complicating design modifications.
Code that is hard to modify without afecting other areas.
Unnecessary code that can be safely removed.
Excessive coupling between components, complicating dependency management.
Issues with data encapsulation and information hiding.
Examples of Code Smells Long Method, Large Class, Long Parameter List Switch Statements, Refused Bequest Divergent Change, Shotgun Surgery Duplicated Code, Dead Code Feature Envy, Message Chains Inadequate Encapsulation, Lack of Information Hiding 2. Design-focused. Concerned with the structure, flows, and requirement definitions of the software.
It´s important to point out that design-focused metrics are more dificult to measure as they cannot be assessed solely by evaluating code or class relationships. To measure these metrics, one must analyze how the code serves as a resource, how design patterns are applied, and how class interactions reveal the overall flow and architecture of the system.
A code smell is an indicator in source code that suggests potential problems in the software’s structure
or design, leading to issues such as poor maintainability, increased complexity, or future bugs. These
smells often signal the need for refactoring to improve code quality and readability [
Martin Fowler, in Refactoring: Improving the Design of Existing Code, identifies 22 types of code
smells, categorized to highlight common issues that impede code maintainability, comprehension, or
extensibility. Notable examples include Long Method, Large Class, Divergent Change, and Feature Envy,
which often require refactoring [
The relationship between code smells and software quality attributes is key to this study. Metrics
assess code quality by reflecting attributes such as maintainability and scalability, and these attributes
can be afected by specific code smells. Moreover, each smell is linked to a refactoring technique,
creating a bridge between metrics, code smells, and quality attributes [
Table 1 categorizes code smells by the type of issue they pose, ofering a structured approach for identifying and addressing these during code reviews and refactoring sessions.
By linking code smells with refactoring techniques and quality attributes, this study aims to provide comprehensive feedback to both students and professionals, helping them improve their software by addressing quality-related issues more efectively.
The metrics for evaluating source code are often based on quality attributes [
Table 2 presents the ISO/IEC 25010 software quality model (SQuare). This framework defines key attributes that contribute to the enhancement of software products. The ISO/IEC 25010 model classifies quality into eight distinct characteristics. By systematically evaluating these attributes, the model Performance Compatibility Usability
Description The ability of software to provide functions that meet the needs expressed by the business. This includes aspects such as correctness, completeness, and suitability.
The ability of the software to be transferred from one environment to another. This includes installability, replaceability, adaptability, and co-existence with other software.
It is the ability of the software to operate in diferent environments.
It is the ability of the software to be easily used. Mainly, it refers to the aesthetics of the user interfaces. The aim is for the user to be able to learn very quickly how to use the software.
The ability of software to tolerate failures over time under given conditions.
The software’s ability to protect and secure data from being read or extracted by third parties.
The ability of the software to efectively implement a change in components.
The ability of the software to be transferred from one environment to another. ensures that the software can efectively meet user needs. The achievement of these quality attributes in our approach is crucial for user satisfaction.
Software architecture is based on non-functional requirements as a way to evaluate software quality. Most companies that produce software products implement QA processes. These processes can be guided by the standards that are already in place for the diferent entities.
Table 3 presents the main standards that exist today to evaluate and understand the quality of software. The ISO organization presents standards to create a software quality model. Additionally, it presents frameworks to define security and metrics to measure attributes (ISO/IEC 2502), focusing on the measurement and assessment of software attributes to ensure that they meet user needs and quality requirements. The Institute of Electrical and Electronics Engineers (IEEE) organization presents a quality assurance process and defines the software life cycle. The Object Management Group (OMG) organization presents metrics for software assurance (SwA). SwQ is a set of standards to measure the security, reliability, and resilience attributes of software systems throughout their life cycle. These metrics focus on identifying and mitigating risks related to software vulnerabilities to build reliable software products. The National Institute of Standards and Technology (NIST) provides a comprehensive set of security controls to ensure software quality through rigorous security measures. They also introduce quality metrics to assess software quality attributes such as performance, reliability, and maintainability to ensure that software products meet high standards of excellence. The American Productivity & Quality Center (APQC) provides a framework for organizations to improve their quality management processes through efective practices such as continuous improvement, process optimization, customer focus, and performance measurement, helping organizations to achieve quality.
Table 4 presents the tools for generating unit tests and measuring suitability and functional adequacy in projects built in Python and Java. In Python, PEP 8 is the style guide for Python code that provides conventions for readable and consistent code. It covers several aspects of coding style, including naming conventions, code layout, indentation, and documentation. By properly using this PEP 8 guide, you can produce more maintainable code, which facilitates better collaboration and reduces the likelihood of bugs in Python projects. Additionally, this table presents a comparison of various quality attributes and the tools used to assess these attributes in the Java and Python programming languages. Java tools include SonarQube, VisualVM, YourKit, CheckStyle, FindBugs, PMD, OWASP Dependency-Check, and JMeter, while Python tools include SonarQube, Pytest, Radon, Tox, Pyenv, Py-Spy, CProfile, Flake8, Pylint, and Bandit. This comparison helps identify the tools available to maintain and improve software quality.
To determine whether the software project complies with the object programming paradigm, the following can be reviewed:
Encapsulation • Python. Class attributes are declared as private with a double underscore prefix to encapsulate them. Additionally, provide getter and setter methods to access and modify private attributes. • Java. Use access modifiers (private, protected, public) to control access to class members. Encapsulate data fields by declaring them private and providing public getter and setter methods.
• Python. Use subclasses to create new classes that inherit attributes and methods from parent classes. Also, ensure that subclass methods override superclass methods when necessary. • Java. Use the extends keyword to create subclasses that inherit from parent classes. Apply the @Override annotation when overriding superclass methods to ensure correct behavior. • Python. Use method overriding and overloading to achieve polymorphic behavior. Additionally, implement polymorphism through duck typing, where objects are judged based on their behavior rather than their type. • Java. Achieve polymorphism through method overriding and overloading. Use inheritance and interfaces to define common behaviors and allow objects of diferent classes to be treated uniformly. • Python. Use abstract base classes (ABC) from the abc module to define abstract methods and implement interfaces. Implement abstract classes that provide a model for subclasses to follow. • Java. Define abstract classes and methods using the abstract keyword. Use interfaces to define contracts for classes and provide a form of multiple inheritance.
In software engineering, metrics are crucial to assess various aspects of software quality. These metrics
can be categorized according to their focus: some target runtime issues (code) [
The concept of code smells is popularized by influential authors such as Martin Fowler and Robert
C. Martin, who refer to indicators of potential internal problems within software [
Recent research indicates that current tools can detect many of the code smells defined by Fowler, but there is still a need for tools that support a wider range of programming languages. Tools such as DECOR/DETEX can identify various code smells using Domain-Specific Languages (DSL), but the number of detectable smells has been increasing to meet new software requirements.
Each code smell is associated with specific quality attributes, both internal and external.
Understanding these relationships is essential because refactoring to address one code smell can sometimes lead to
new smells, creating a cycle of software deterioration. This underscores the importance of exploring
how refactoring afects code smells and overall quality [
Machine learning techniques are increasingly used to measure performance, usability, and security
attributes, often focusing on runtime rather than design-time issues [
The metrics related to maintainability are particularly significant due to their impact on development
costs. Prioritizing metrics according to their relevance in industry and academia can help to organize
these attributes by their importance and impact [
Several established metrics from companies such as McCabe, renowned for their pioneering contributions to software engineering in the 1990s, focus on various aspects of software analysis including • Cyclomatic Complexity (CC) • Essential Complexity (EC) • Module Design Complexity (MDC) • Module Integration Complexity (MIC) • Weighted Methods per Class (WMC) • Depth of Inheritance Tree (DIT) • Number of Children (NOC) • Coupling Between Object Classes (CBO) • Response for a Class (RFC • Lack of Cohesion of Methods (LCOM) security, quality, release management, and overall software process management. McCabe’s metrics are designed to provide deep insights into the structure and behavior of software systems, helping in the identification of potential risks and areas for improvement. Metrics include:
Chidamber and Kemerer [
Lorenz and Kidd [
Fernando Brito e Abreu [
According to related work, code smells and metrics are strongly related to quality attributes. The metrics mentioned above are primarily concerned with how each one can be measured. For example, McCabe suggests Cyclomatic Complexity, one of the easiest metrics to measure because it can be analyzed using regular expressions without requiring relationships, indicating lower coherence. In this study, we aim to explore these relationships and evaluate the feasibility of each metric, to better connect these concepts and provide more valuable feedback for practitioners and students.
Quality measurement in software development is the process of evaluating various attributes and user satisfaction against business needs. By systematically measuring these attributes, developers can identify defects, optimize performance, and ensure that software meets user expectations and business requirements. Efective quality measurement is crucial to delivering high-quality software, reducing development costs, and maintaining customer trust.
Quality Code System (QuUD) is the name of the system. QuUD will measure code quality following a circular flow to ensure code inspection. The system has two main roles: the admin generates and handles the rules, code owner is the users who generate inspections. Figure 1 presents the general process. The process starts with the administrators’ configuration of quality rules. The administrators must establish specific standards and criteria to be applied to the Java and Python languages for each quality attribute. A weight will be defined for each attribute. Additionally, rules are established to determine if the project complies with the object-oriented programming paradigm.
Once the rules are defined, the project owners must register in the system and link their source code repositories. This step is done by connecting the code that must be on GitHub to automatically analyze the code. Initially, the repository must be public.
By linking the project, the project owners will be able to initiate quality inspections. By starting an inspection, the system must extract the code from the repositories and execute the analysis according to the predefined quality rules. The inspection process involves evaluating the code in terms of the attributes defined in Table 2 and checking if OOP paradigm is achieved based on 2.4. Once the inspection is complete, the system will send a push notification to the project owner with the results. The idea of the report is to provide a score for each attribute. Additionally, an overall score of the result will be displayed. Code owners can review the results to make corrections that improve the quality of the software. The steps ensures that the code is evaluated multiple times according to the established rules.
To calculate the source code inspection score, a static scan of the code is performed to assess whether it complies with the OOP paradigm. Additionally, an evaluation of the attributes is performed. Rules are defined for each attribute and for the OOP paradigm. Thus, a weight is defined for each attribute and a weight to determine whether it complies with the OOP paradigm. Then, a score is generated for each attribute and for OOP. Then, a final score is calculated. To calculate the source code inspection score, follow this procedure: 1. Calculate the score of the quality attribute: 3. Total Paradigm Score Calculation: 4. Calculating the Final Inspection Score: Where:
Final Score = × Total Attribute Score + (1 − ) × Total Paradigm Score • : It is a weighting factor that determines the relative importance between attributes and paradigm compliance (with 0 ≤ ≤ 1). • : Score obtained for the attribute . • : Weight assigned to the attribute . • : Score obtained for compliance with the paradigm . • : Weight assigned to the paradigm . • : Total number of rules of quality attributes.
• : Total number of rules to determine if it complies with the OOP programming paradigm.
QuUD is composed of backend and frontend components. Figure 2 shows the architecture of the system. For authentication, the Firebase Auth service will be used. This will allow for diferent authentication mechanisms such as Gmail, User-password, text message, etc. In the front, there are two main subcomponents, the code-scanner will be in charge of allowing project owners to register, link their projects, and consult the results of the inspections. In the front, the other component is the Admin, which will mainly be in charge of managing the inspection rules. In the Backend, there are two databases. The ifrst is the real-time database, which will be in charge of saving events about whether the inspections have finished or if an inspection should be started. The PostgreSQL database will save the results of the inspections. In the backend, there are three sub-components: • Project extractor: It is responsible for connecting to the repositories and starting the scan. Also, this sub-component calculates if is a Java or Python project. • Event handler: It mainly receives two events, scan start and scan end. When the scan starts the Engine Scanner sub-component receives the event. When the scan ends the Web - Code Scanner sub-component receives the event and queries the Project Extractor sub-component to display the ifnal result. • Scanner engine: This is the main component of the project, responsible for receiving the rules and the source code to start calculating the inspection result. The static code scanning will be focused on evaluating whether the OPP paradigm is well implemented. Additionally, each quality attribute will be evaluated.
Metrics focused on performance and scalability require diferent approaches. Some of them use machine learning techniques to learn what input causes stress in applications. Our model is focused on code, specifically for detecting issues through mapping strings, that can afect performance but not in the execution or from an experimental perspective. The detection of what can stress applications could help to detect what problems in code cause weakness in performance and scalability.
The development of the model proposed lets us go to the next steps, more related to experiments in the focused area, of academics. We recommend the use of SCRUM and Agile methodology after defining product requirements. Also, it is necessary to take design and UI into the development process because, due to students and teachers it’s important to make it easy to use. Another part is the infrastructure design, which requires services and tools to support events and preserve data. This definition includes the next steps after application design and it has to take requirements according to the amount of users in the academic area who are going to use the application for the first time.
Other programming languages, such as C++, Javascript, Golang, Rust, and Kotlin are also considered in this study as a future extension of our approach. The rise of event-driven architectures and the development of mobile and single-page applications have led to the creation of new languages that address emerging requirements, such as enhanced performance and management of advanced technologies like event-driven databases.
Other domains require a diferent approach, firstly we aim to support students and lecturers in the academic area, but it could be useful to support practitioners. The enterprise domain requires diferent communication, because the objective is diferent. A company focuses on revenue because the development has to be quick and sometimes is necessary to give more importance to some quality attributes at the beginning. For example, for the development of a new product, companies can use monoliths keeping coupling in mind for some features and they can go fast for the launch of applications, and with results they can validate if the product evolves or not.
Efective communication of metrics is crucial to the evolution of our approach. However, this can be challenging, especially as the number of variables increases. It becomes more dificult to convey not only the metrics themselves but also the related quality attributes, both general and specific. It’s important to enhance the evaluated application while simultaneously guiding users on how to address any identified issues.
The idea is to generate a mechanism to evaluate whether the model is correct. In a subsequent article, diferent projects will be made as case studies. The idea is to check whether the scores are being calculated correctly according to the principle of the OOP paradigm (encapsulation, abstraction, inheritance, polymorphism, etc.) and whether the quality attribute is improved.
Although there is not a clear relation between code smells and metrics, in the specific area of
programming, code smells deteriorate metrics, and studying this relation could give us the capacity to provide
better feedback, with accuracy because once we have this relation we can add refactoring techniques.
According to this study [
This paper explains the diferent quality attributes that a software code can have. A system was proposed that will be able to control the quality of source code for Python and Java using a rules engine. The system must evaluate the quality attributes and whether it complies with the object-oriented paradigm.
We proposed a novel way of calculating the quality of the code by scoring it based on the quality attributes and whether it complies with the object-oriented paradigm. If it complies with the objectoriented paradigm, the software project can guarantee the sole responsibility of the SOLID principle. Additionally, in an academic context, students will be able to know if they are using the principles of the paradigm correctly.
Software quality should not be neglected and, on the contrary, mechanisms or models must be in place to ensure quality. It is important to measure quality in terms of quality attributes because if you are in a software development phase, you can establish in the design phase which attributes the system should prioritize.