Maintaining the quality of the code

Quality in Code is one of the most important things in programming. So, maintaining the quality of the code is very important.

Here are the main attributes that can be used to determine code quality:

• Clarity

Easy to read and oversee for anyone who isn’t the creator of the code? If it’s easy to understand, it’s much easier to maintain and extend the code. Not just computers, but also humans need to understand it.

• Maintainable

 A high-quality code isn’t over complicated. Anyone working with the code has to understand the whole context of the code if they want to make any changes.

• Documented

The best thing is when the code is self-explaining, but it’s always recommended to add comments to the code to explain its role and functions. It makes it much easier for anyone who didn’t take part in writing the code to understand and maintain it.

• Refactored

Code formatting needs to be consistent and follow the language’s coding conventions.

• Well-tested

The less bugs the code has the higher its quality is. Thorough testing filters out critical bugs ensuring that the software works the way it’s intended.

• Extendible

The code you receive has to be extendible. It’s not really great when you have to throw it away after a few weeks.

• Efficiency

High-quality code doesn’t use unnecessary resources to perform a desired action.

A quality code does not necessarily meet all of the above-mentioned attributes, but the more it meets, the higher its quality. These requirements are more like a priority list that depends on the characteristics of your business.

If you get excited by quantitative measurement and want to put metrics behind code quality measurement, you could apply the following software metrics:

• Weighted Micro Function Points
• Halstead complexity measures

·          
               Cyclomatic Complexity

·                             Lines of code

·                            Lines of code per method

·

Ok, then we talk about measure the quality of code.

Code metrics

Code analysis tools are great when used by developers as an aid to find areas of the system that could be improved. They are great to highlight things that are not always easily seen with a naked eye. They may also be very helpful when working with legacy code. However, the problem with code metrics is that making sure that the code complies to specific metrics is very different from saying that the code has quality. Having high test coverage is not the same as having good tests. Having loose coupled and high cohesive code doesn't mean code that express the business domain or that is very easy to understand. Code with low cyclomatic complexity doesn't mean code that behaves according business specifications and is bug free.

Non-code related metrics

How long does it take to build a new feature? How hard is to deploy the application? How many bugs are found in production every time we go live? How often do we go live? How fast can we safely and confidently change the software to accommodate the ever changing business requirements? Those are all things that we could associate with code quality, but can they be really associated to it? Are all these things only related to the quality of the code? Let's take two common non-code related metrics as examples.

• Number of bugs: What type of bugs have been raised? Are they related to the bad state of the code base, the lack of skills of the developer that implemented the code, bad requirements, or a complete lack of communication between business, developers, and testers?
• Time to deliever a feature: Why are we unhappy about the time it took us to deliver a feature? Is is because of bad estimations? Is it because we were doing something that we haven't done before and we had to explore different alternatives? Were we blocked by other teams or internal bureaucracy? How does this feature compare to previous features implemented in the system? Are they similar? Completely different?
• Documenting the code. Comments improves the readability and the understandability of the code.
• Regular Code Reviews. According to arecent survey, software professionals rankcode reviewsas the number one way to improve programming. These reviews enable developers to collaborate and share knowledge with each other, which improves their work. Furthermore, reviews ensure that code adheres to established standards.
• Functional Testing. Functional testing is important because it encourages developers to focus on software functionality from the outset, reducing extraneous code. The aim of software development is to write an application that delivers exactly what users need.
• Clear Requirements. Most software development projects begin with a requirements document, or story cards in agile development. A project with clear, feasible requirements is much more likely to achieve high quality than ambiguous, poorly specified requirements.

As you can see, there are just too many variables involved, which makes it impossible to have a precise way to measure quality.

Can we really judge the quality of our code according to the amount of time we take to build a new feature or number of bugs? I don't think so. Does the state of the code base impact on our speed of delivery and number of bugs? Yes, definitely. Is the state of the code base the sole responsible for delays and bugs? No. But, as a developer, can we feel that the state of the code is dragging us down and helping us to make mistakes? Absolutely. Can we define a set of metrics that would define quality according to how we feel? I really doubt.

Ok now we going to discuss and compare some available tools to maintain the code quality.

        1. SonarQube

            SonarQube is an open-source platform developed by SonarSource for continuous inspection
            of code quality to perform automatic reviews with static analysis of code to detect bugs, code
            smells, and security vulnerabilities on 20+ programming languages

        2. SonarSource

SonarSource solutions support development in 25+ programming languages such as Java, C#, JavaScript, TypeScript, C/C++, COBOL and many more.

With over 3,000 customers including eBay, Thales, BMW and used by more than 120,000 organizations globally, SonarSource products are the preferred and most trusted solutions on the market.

       3. CSS LINT

CSS Lint is a tool to help point out problems with your CSS code. It does basic syntax checking                   as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency. The rules are all pluggable, so you can easily write your own or omit ones you don't want.

     4. Klocwork

Unlike other static code analysis tools, Klocwork integrates seamlessly into desktop IDEs, build systems, continuous integration tools, and any team's natural workflow. Mirroring how code is developed at any stage, Klocwork prevents defects and finds vulnerabilities on-the-fly, as code is being written.

Klocwork also helps prioritize work with SmartRank, the revolutionary new recommendation engine that prioritizes issues and helps select which ones to work on first.

Take prioritized, corrective action immediately to deliver more secure and reliable code.

Why need for dependency/package management tools in software development

Dependencies are a cornerstone of modern web development. These are the required tools, plugins, libraries and frameworks necessary to build high-level web applications.

The sheer number of dependencies has skyrocketed in the last few years. Over time developers have adopted dependency management tools which alleviate the stress of keeping dependencies organized and up-to-date. These tools lead to an optimized workflow for developers and project managers.

There are tools to manage these external artefacts towards minimizing these issues

1. Composer

Composer is a package manager. It’s focused on PHP libraries. You can find a list of dependencies on Packages which includes large PHP frameworks such as Laravel. If you’re a PHP developer of any kind I seriously recommend looking into Composer. It’s easy to get started but difficult to fit into your workflow. However with practice it’ll become a staple for PHP developing projects.

2. NPM

 

I couldn’t write this guide without giving credit to the Node Package Manager. Built on Node.js, this system powers a tremendous repository of 100,000+ packages and modules.

Each project can use a package. json file setup through NPM and even managed with Gulp(on Node). Dependencies can be updated and optimized right from the terminal. And you can build new projects with dependency files and version numbers automatically pulled from the package. json file.NPM is valuable for more than just dependency management, and it’s practically a must-know tool for modern web development. If you’re confused please check out this Reddit thread for a beginner’s explanation.

3. Bower

The package management system Bower runs on NPM which seems a little redundant but there is a difference between the two notably that NPM offers more features while Bower aims for a reduction in filesize and load times for frontend dependencies. Check out this Stack question to learn more about the subtle differences.

4. Maven

 Maven is a multi-purpose tool. Maven can Making the build process easy, Providing a uniform build system, Providing quality project information, Providing guidelines for best practices development.

Now we are going to discuss about build tools

A build tool is a programming utility that is used when building a new version of a program. For example, make is a popular open source build tool that uses make file, another build tool, to ensure that source files that have been updated (and files that are dependent on them) will be compiled into a new version (build) of a program.

·         Build tools are programs that automate the creation of executable applications from source code.

·         Building incorporates compiling, linking and packaging the code into a usable or executable form.

·         In small projects, developers will often manually invoke the build process. This is not practical for larger projects, where it is very hard to keep track of what needs to be built, in what sequence and what dependencies there are in the building process. Using an automation tool allows the build process to be more consistent

Build automation

·        On-demand automation such as a user running a script at the command line.

·        Scheduled automation such as a continuous integration server running a nightly build.

·        Triggered automation such as a continuous integration server running a build on every commit to a version-control system.

BUILD TOOLS

                             

                                                        

                                              

Ant with Ivy

Ant was the first among “modern” build tools. In many aspects it is similar to Make. It was released in 2000 and in a short period of time became the most popular build tool for Java projects. It has very low learning curve thus allowing anyone to start using it without any special preparation. It is based on procedural programming idea.
After its initial release, it was improved with the ability to accept plug-ins.
Major drawback was XML as the format to write build scripts. XML, being hierarchical in nature, is not a good fit for procedural programming approach Ant uses. Another problem with Ant is that its XML tends to become unmanageably big when used with all but very small projects. Later on, as dependency management over the network became a must, Ant adopted Apache Ivy.

Maven

Maven was released in 2004. Its goal was to improve upon some of the problems developers were facing when using Ant.
Maven continues using XML as the format to write build specification. However, structure is diametrically different. While Ant requires developers to write all the commands that lead to the successful execution of some task, Maven relies on conventions and provides the available targets (goals) that can be invoked. As the additional, and probably most important addition, Maven introduced the ability to download dependencies over the network (later on adopted by Ant through Ivy). That in itself revolutionized the way we deliver software.
However, Maven has its own problems. Dependencies management does not handle conflicts well between different versions of the same library (something Ivy is much better at). XML as the build configuration format is strictly structured and highly standardized. Customization of targets (goals) is hard. Since Maven is focused mostly on dependency management, complex, customized build scripts are actually harder to write in Maven than in Ant.
Maven configuration written in XML continuous being big and cumbersome. On bigger projects it can have hundreds of lines of code without actually doing anything “extraordinary”.
Main benefit from Maven is its life-cycle. As long as the project is based on certain standards, with Maven one can pass through the whole life cycle with relative ease. This comes at a cost of flexibility.
In the meantime the interest for DSLs (Domain Specific Languages) continued increasing. The idea is to have languages designed to solve problems belonging to a specific domain. In case of builds, one of the results of applying DSL is Gradel.

Gradle

Gradle combines good parts of both tools and builds on top of them with DSL and other improvements. It has Ant’s power and flexibility with Maven’s life-cycle and ease of use. The end result is a tool that was released in 2012 and gained a lot of attention in a short period of time. For example, Google adopted Gradle as the default build tool for the Android OS.
Gradle does not use XML. Instead, it had its own DSL based on Groovy (one of JVM languages). As a result, Gradle build scripts tend to be much shorter and clearer than those written for Ant or Maven. The amount of boilerplate code is much smaller with Gradle since its DSL is designed to solve a specific problem: move software through its life cycle, from compilation through static analysis and testing until packaging and deployment.Initially, Gradle used Apache Ivy for its dependency management. Later own it moved to its own native dependency resolution engine. Gradle effort can be summed as “convention is good and so is flexibility”.

Apache Maven Dependency Plugin

The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location.

 

Maven Code Style sand Code Conventions

This document describes how developers and contributors should write code. The reasoning of these styles and conventions is mainly for consistency, readability and maintainability reasons.

Generic Code Style and Convention

All working files (java, xml, others) should respect the following conventions:

• License Header: Always add the current ASF license header in all versioned files.
• Trailing Whitespaces: Remove all trailing whitespaces. If you are an Eclipse user, you could use the any edit Eclipse Plugin.

Following style using Maven:

• Indentation: Never use tabs!
• Line wrapping: Always use a 120-column line width.

The specific styles and conventions, listed in the next sections, could override these generic rules.

MAVEN – BUILD LIFE CYCLE

·         A Build Lifecycle is a well-defined sequence of phases, which define the order in which the goals are to be executed

·         The primary(default) life cycle of Maven is used to build the application, using 23 phases

·         Validate

·         Initialize

·         Generate-sources

·         Compile

·         Generate-test-sources