INDUSTRY PRACTICES AND TOOLS 2

Code standards

Coding standards, sometimes referred to as programming styles or coding conventions, are a very important asset to programmers. Standards are rules which a developer is expected to follow. However, these rules, such as “the compiled file must have the extension .h” are often apparent are followed anyway. Guidelines, however, are much less well followed. They are stylistic measures which have no direct effect on the compilation of the guide and exist only to make the source code more humanly readable. They are optional but highly recommended.

Why Is Good Quality Code So Important?

A good quality code is an essential property of software because it could lead to financial losses or a waste of time needed for further maintenance, modification or adjustments if code quality is not good enough.

The long-term usefulness and long-term maintainability of the code, minimize errors and easily debugged, improve understandability, Decrease risks.

Characteristics of Good Quality Code

• Efficiency
• Reliability
• Robustness
• Portability
• Maintainability
• Readable
•  Readable

1. Efficiency

Directly related to the performance and speed of running the software.

Why important?

The quality of the software can be evaluated with the efficiency of the code used. No one likes to use a software that takes too long to perform an action.

How?
Remove unnecessary or redundant code o Write reusable code
 Reduce resource consumption
 Use appropriate data types, functions and looping in appropriate place

2. Reliability

Ability to perform consistent and failure-free operations every time it runs.

Why important?

The software would be very less useful if the code function differently every time it runs even with the same input in same environment and if it breaks down often without throwing any errors.

How?
Take much time to review and test the code carefully and thoroughly in every possible way.
 Use proper error and exception handling
 Ability to perform consistent and failure-free operations every time it runs.

3. Robustness

Ability to cope with errors during program execution even under unusual condition.

Why important?

Image how would you feel when you use a software that keep showing strange and unfamiliar message when you did something wrong. Software is typically buggy and fragile but it should handle any errors encountered gracefully.

How?
Test software from every condition; both usual and unusual. Use proper error and exception handling 
Use proper error and exception handling.

4.  Robustness

Ability of the code to be run on as many different machines and operating systems as possible.

Why important?

It would be a waste of time and energy for programmers to re-write the same code again when it transferred from one environment to another.

How?

Start from the very beginning, write code that could work on every possible environment.

5. Maintainability

Code that is easy to add new features, modify existing features or fix bugs with a minimum of effort without the risk of affecting other related modules.

Why important?

Software always needs new features or bug fixes. So the written code must be easy to understand, easy to find what needs to be change, easy to make changes and easy to check that the changes have not introduced any bugs.

How?
Take much time to review and test the code carefully and thoroughly in every possible way.
 Use proper error and exception handling
Ability to perform consistent and failure-free operations every time it runs.

6. Readable

Ability to cope with errors during program execution even under unusual condition.

Why important?

Image how would you feel when you use a software that keep showing strange and unfamiliar message when you did something wrong. Software is typically buggy and fragile but it should handle any errors encountered gracefully.

How?
Good naming of variable, method and class names
Use of proper indentation and formatting style
Good technical documentation
Write appropriate comment or summary descriptions at the top of files, classes or functions.

The quality of the code can be measured by different aspects

     1.    Weighted Micro Function Points

modern software sizing algorithm invented by Logical Solutions in 2009 which is a successor to solid ancestor scientific methods as COCOMO, COSYSMO, maintainability index, cyclomatic complexity, function points, and Halstead complexity. It produces more accurate results than traditional software sizing methodologies while requiring less configuration and knowledge from the end user, as most of the estimation is based on automatic measurements of existing source code.

     2.    Halstead Complexity Measures

Halstead complexity measures are software metrics introduced by Maurice Howard Halstead in 1977[1] as part of his treatise on establishing an empirical science of software development. Halstead made the observation that metrics of the software should reflect the implementation or expression of algorithms in different languages, but be independent of their execution on a specific platform. These metrics are therefore computed statically from the code.

Halstead's goal was to identify measurable properties of software, and the relations between them. This is similar to the identification of measurable properties of matter (like the volume, mass, and pressure of a gas) and the relationships between them (analogous to the gas equation). Thus, his metrics are actually not just complexity metrics.  

     3.    Cyclomatic Complexity

Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.

     4.    Lines of code

     5.    Lines of code per method

Impact of Quality code

      1.      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.

     2.      Maintainable:

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

     3.      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.

     4.      Refactored:

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

     5.      Well-tested:

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

     6.      Extensible:

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

     7.      Efficiency:

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

To Improve Readability of Code

       ·         Use of Comments

       ·         Appropriate naming

       ·         Proper indention

    1.    Use of Comments
     Provide the programmers with additional information about the written code allowing them to
      easily understand
      the purpose and reason behind a piece of code, 
      what a piece of code would do and
      what you are trying to accomplish with it. 
      Allows you to talk to your fellow developers about the business needs, special-requests,
      remaining tasks and the temporary solutions. 
      Proper use of commenting can make code maintenance much easier, as well as helping in 
      finding bugs faster. 
      Reduce the effort and time needed to read and try to understand a previously written code.

     2.    Appropriate Naming
             Have a significant role in program readability
       Make it noticeably easier for programmers to quickly determine what the code is doing, and to 
       fixed or modify for further requirements.
       components play.

    3.    Proper Indention

      Guides programmers where they should follow and implement, fix or make changes in coding.

      Makes the structure of the code more obvious, making it easier to follow improving the readability of the code.

      If the indention is poorly done, other programmers are going to have a hard time following your code and determining when a block executes.

ü  Proper code indentation will make it:

ü  Easier to read

ü  Easier to understand

ü  Easier to modify

ü  Easier to maintain

ü  Easier to enhance

ü  Saving lots of time when we need to revisit the code and use it.

Some suggestions  

•  No duplication
• Well-factored 
• Conceptual integrity 
• Intentional naming 
• Low complexity
• Strong cohesion
• Weak coupling
• Lean and mean
• Simple
• Testable
• Readable
• Not too smart
• Consistent
• Uniform
• Imperfect
•      Flat

Best Code Review Tools in the Market

Dependency management

Software project may have a backbone framework and many external artefacts linked

·         Third party packages

·         External libraries

·         Plug-ins

·         Etc.

These external artefacts may introduce many integration issues

·         Different folder/file structures and may use different ways of integrating into the main framework.

·         Different external artifacts may use different ways of integration

·         Different versions are available and difficult to upgrade.

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

·         Composer [php]

·         Maven [Java]

·         NuGet[.net]

·         NPM (Node Package Manager) [JS]

·         Bower [JS]

Build Tool

What does Build Tool mean?

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 utilities allow the automation of simple, repeatable tasks. When using the tool, it will calculate how to reach the goal by executing tasks in the correct, specific order and running each task. The two ways build tools differ are task-oriented vs. product-oriented. Task-oriented tools describe the dependency of networks in terms of a specific set task and product-oriented tools describe things in terms of the products they generate.

Basically, build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities like:

·         Downloading dependencies.

·         Compiling source code into binary code.

·         Packaging that binary code.

·         Running tests.

·         Deployment to production systems.

Advantages

The advantages of build automation to software development projects include

A necessary pre-condition for continuous integration and continuous testing

Improve product quality

Accelerate the compile and link processing

Eliminate redundant tasks

Minimize "bad builds"

Eliminate dependencies on key personnel

Have history of builds and releases in order to investigate issues

Save time and money - because of the reasons listed above.

Various build tools available (Naming only few):

·         For java - Ant, Maven, Gradle.

·         For .NET framework - NAnt

·         C# - MsBuild.

Build automation

In the context of software development, build refers to the process that converts files and other assets under the developers' responsibility into a software product in its final or consumable form. The build may include:

·         compiling source files

·         packaging compiled files into compressed formats (such as jar, zip)

·         producing installers

·         creating or updating of database schema or data

The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.

Expected Benefits

Build automation is a prerequisite to effective use of continuous integration. However, it brings benefits of its own:

eliminating a source of variation, and thus of defects; a manual build process containing a large number of necessary steps offers as many opportunities to make mistakes

requiring thorough documentation of assumptions about the target environment, and of dependencies on third party products

Types

·         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.

Advantages

·         A necessary pre-condition for continuous integration and continuous testing •Accelerate the compile and link processing

·         Eliminate redundant tasks

·         Minimize "bad builds"

·         Documentation –has the history of builds and releases in order to investigate issues

·         Save time and money, and improve product quality

What is Maven and Maven - Build Life Cycle

Maven uses Convention over Configuration, which means developers are not required to create build process themselves. Developers do not have to mention each and every configuration detail. Maven provides sensible default behavior for projects.

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, Etc.

What is Build Lifecycle?

A Build Lifecycle is a well-defined sequence of phases, which define the order in which the goals are to be executed. Here phase represents a stage in life cycle. As an example, a typical Maven Build Lifecycle consists of the following sequence of phases

There are always pre and post phases to register goals, which must run prior to, or after a particular phase.

When Maven starts building a project, it steps through a defined sequence of phases and executes goals, which are registered with each phase.

Maven has the following three standard lifecycles −

•           clean

•           default(or build)

•           site

A goal represents a specific task which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The clean and package arguments are build phases while the dependency: copy-dependencies is a goal.

mvn clean dependency: copy-dependencies package

Here the clean phase will be executed first, followed by the dependency: copy-dependencies goal, and finally package phase will be executed.

Clean Lifecycle

When we execute mvn post-clean command, Maven invokes the clean lifecycle consisting of the following phases.

•           pre-clean

•           clean

•           post-clean

Maven clean goal (clean: clean) is bound to the clean phase in the clean lifecycle. Its clean:cleangoal deletes the output of a build by deleting the build directory. Thus, when mvn clean command executes, Maven deletes the build directory.

We can customize this behavior by mentioning goals in any of the above phases of clean life cycle.

In the following example, We'll attach maven-antrun-plugin:run goal to the pre-clean, clean, and post-clean phases. This will allow us to echo text messages displaying the phases of the clean lifecycle.

We've created a pom.xml .

Now open command console, go to the folder containing pom.xml and execute

Default (or Build) Lifecycle

This is the primary life cycle of Maven and is used to build the application. It has the following 21 phases.

validate

Validates whether project is correct and all necessary information is available to complete the build process.

initialize

Initializes build state, for example set properties.

generate-sources

Generate any source code to be included in compilation phase.

process-sources

Process the source code, for example, filter any value.

generate-resources

Generate resources to be included in the package.

process-resources

Copy and process the resources into the destination directory, ready for packaging phase.

compile

Compile the source code of the project.

process-classes

Post-process the generated files from compilation, for example to do bytecode enhancement/optimization on Java classes.

generate-test-sources

Generate any test source code to be included in compilation phase.

process-test-sources

Process the test source code, for example, filter any values.

test-compile

Compile the test source code into the test destination directory.

process-test-classes

Process the generated files from test code file compilation.

test

Run tests using a suitable unit testing framework (Junit is one).

prepare-package

Perform any operations necessary to prepare a package before the actual packaging.

package

Take the compiled code and package it in its distributable format, such as a JAR, WAR, or EAR file.

pre-integration-test

Perform actions required before integration tests are executed. For example, setting up the required environment.

integration-test

Process and deploy the package if necessary, into an environment where integration tests can be run.

post-integration-test

Perform actions required after integration tests have been executed. For example, cleaning up the environment

verify

Run any check-ups to verify the package is valid and meets quality criteria.

install

Install the package into the local repository, which can be used as a dependency in other projects locally.

deploy

Copies the final package to the remote repository for sharing with other developers and projects.

There are always pre