Hot To Code Quality ...

Today the business world is so dynamic. Expectations, needs and wants of people are changing instantly at non predeterministic unpredictable way. So do the Business Requirements. Hence it is inevitable that the software you develop today will always in need of dynamically changing it's capabilities in order to cater the various changing customer expectations. The challenge is exceptionally high, as in this industry (Software Industry), the technologies are changing even at a faster rate. This back ground paves the way for this article, on the need of writing quality code.  What do you mean by quality code?, why code quality is this so important? And how you write a quality code and what are the areas to think about? Following is a research about the same. 

As provided the dynamic nature of the industry, Software cannot be developed for life time, so that they meet the requirements of everybody for every day.  Therefore once the requirements change for existing customers, or once the existing product is needed for new customers with some modification, the product will have to scale or enhance for new features. When new technologies arise, and when new dependencies are introduced,   when you find bugs and vulnerabilities, you will have to maintain your product for stabilization. In either ways it is part partial that you maintain your product to remain sustain in the business. So code quality is directly involved with the sustain Engineering of any software product. Today many software companies spend millions of money in maintaining their products. Sometimes one would not believe, that generally maintenance cost top your cost structure of annual reports for majority of Software Development Organizations. Therefore " A quality code" is strategically such very important as it is the only sustainable way for your organization to reduce the rocketing maintenance costs.  

Following section will look at the issue from more technical perspective and will reveal some vital concepts to help you develop the code quality.

Generally quality of the code can be qualitatively discussed in terms of the following. 

a)      Readability 
b)      Extensibility 
c)       Reusability 
d)      Maintainability 
e)   Testability
f)      Design time concerns - The open closed principle 

Code reviews are the very famous ways of reviewing the existing code, in order to conform that the code meets above.

Readability

Readability of a code is vital as reading the code is the only way so that the feature enhancement developments, bug fixing, maintenance can be easily carry on. It is an inevitable fact in the software industry that original developers may not stay long with the project, so that the developers, who have the actual familiarity of the code, may not stay prolong for the maintenance cycle. With this tentative nature of employment turnover in  the business, generally software organizations may have to start maintenance work with brand new members who have no previous understanding of the code. More over, only very few small and medium scale organizations would maintain the costly learning organization. (design specs, training documentation,  product documentations,  Proper version control, release management, history logs, etc.) Therefore readability of the code is extremely vital for the reduction of maintenance effort and finally the maintenance costs. Readability meaning the ability to easy understand the code, its logic and the functionality it delivers with minimum effort.  For example, there  may be programming STARs who could write logic in two comprehensive lines, which general average developer may take 20 lines for that. However, the negative impact in such a STAR case is, since there is no compromise, shortening the code naturally enhance the complexity. So do it enhance the maintenance effort. Finally the cost of maintaining such bright code will be high compared to an easy readable code.

How do you enhance the readability? 

Readability improves once you reduce the complexity. Complexity may be due to various reasons. It could even include facts like complexity of the logic, complexity of the implementation, complexity of the math, complexity of the usage of programming language (Lambda functions, recursion, nested logics etc.). I consider reducing complexity is one part of enhancing readability. There are there universal coding practices which could help you to reduce the complexity of the code. Here directly i relate my thoughts to what you find in the web. 

1. Partitioning

A concern should be given to logical and understandable way of modularity considering separation of concerns. Partitioning Reduces the number of factors that have to be dealt with simultaneously.  It narrows the focus of attention. However improperly over partitioned, it could enhance the complexity.

2. Hierarchy 

Directs the span of attention and allows for levels of detail. This aids in the later construction and easy understanding of systems. The shape of the hierarchy is important and should reflect the functionality of the system.

3. Independence
 
The most important idea behind a lot of structured design is "High Module Independence" Objective is not simply partitioning a program into a hierarchy but determining the structure such that each module is as independent of all other modules as possible. Independence is generally achieved by minimizing the relationships between different modules (Coupling) and Maximizing the relationships amongst the elements of a particular module (Strength/Cohesion). The independence terms can be also achieved by making the responsibilities independent.

Following too could be very useful in formulating your ethos for readability. No argument about being DRY.  So you are correct. The concerns here are quite coherent with the primitive three facts I described above. 

• Consistency

Applies to formatting, using braces, naming (variables, classes, methods, good uses of white spaces, refactoring)

• Size

If a function doesn't fit in its entirety on the screen in a normal IDE at a normal font size then you need a pretty darn good reason as to why not. Of course there are some valid cases for much longer functions but they are greatly outweighed by the egregious examples. Decompose as necessary to keep your functions simple.

• Comment Judiciously 

There is a tendency for some programmers to use comments as a substitute for readable code or to simply comment for the sake of commenting (like /* finished */ comments right before return true;. Seriously, what's the point? Most (good) code explains itself. 

• Avoid repetitive codes

If you find yourself writing the same sequence of statements (or very similar) over and over again, abstract or parameterize it. If you see very similar statements the tendency is to skim over them assuming they're all the same (when typically they won't be in a way that matters). DRY: DRY stands for Don’t Repeat Yourself. Also known as DIE: Duplication is Evil. The principle states: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

• Careful when you use frameworks

 For example, when you use certain frame works and their inherent features eg: Autowiring of Spring, the introduced dependencies will make things very hard to understand as such frame works hide some layers of operations in the code. This make very hard to understand the code even for those people who have a good understand on the frame work.

• Avoid Deep Nesting

• Use Short BUT meaningful Names

• Single Responsibility Principle

Break code up into meaningful pieces that accomplish specific purposes.

• Clear Design and Separation of Concerns

Separation of responsibility between components (class, function, etc). This will include Keep your classes cohesive (it all works together) and decoupled (there are few dependencies between classes).  On the other hand this can be described as Separation of Code and Data.  Keeping a good modularity and a meaningful folder structure will also be useful here.

Extensibility

In software engineering, extensibility is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions. 

a)  Dependency injection.

Frame Works - provide a reusable context for components 
b) Component Technology (DCOM - Microsoft, SUN - Java Beans) 
c)  Use of Design Patterns 
d) Proper moduleing

Proper moduleing enhance the extendibility as it separates different concerns. 

e)  Separation of interface and implementation

Object-orientation allows us to specify the binding between interface class and implementation class in the following ways 
 i.      Class-based inheritance: whole classes are related by inheritance. The pattern of inheritance is fixed when the classes are created. 
ii.      Delegation: objects can be individually related, enabling each object to make its own decision as to when, and to what, it delegates. The pattern of inheritance can vary dynamically, making delegation a more flexible and powerful way of organizing objects.

Maintainability

Maintainability of the code – Provided the importance of software maintenances and considering the importance of service packs, patches, bug fixes as part of service agreements, or attempts of product stabilization,  here I would focus more on proper documentation, proper release management, proper historical information record and proper versioning on software development than any other fact. The argument is software should well maintainable. In order to track the bugs and the issues, keeping historical records on the releases, is so vital so that developers could easily capture a particular bug to a particular released version or afterwards.  

Reusability

Reusability could be achieved through various concepts that were defined above as well.  However I would also list some concerns below which could be useful when it regards reusability. 

a)    Remove the business logic or main code away from any framework code 
b)   DRY 
c)    Write unit tests for your classes AND make it easy to test classes. (TDD) 
d)    Single responsibility principle 
e)    Try to think more abstractly and use Interfaces and Abstract classes. (dependency injection) 
f)     Reduce coupling 
g)    Be Modular 
h)    SOA Reusability

a.       Services reusability

b.      Services orchestration

c.       Service Automation

Testability

As far as any software project is concerned, testability should be one major design time concern in order to make sure the ultimate functionalities are met. More than that generally large scale software products also  have various test sets, so that before releasing a new version, service pack or, patch, it is a general habit run those vital automated testcases. Orthogonal code design enhance the testability.The things have to consider here include

1. IOC/dependency injection
2. Use of frame works

 Other Design time Concerns - Open Closed principle

The Open Close Principle encourages software developers to design and write code in a fashion that adding new functionality would involve minimal changes to existing code. Most changes will be handled as new methods and new classes. Designs following this principle would result in resilient code which does not break on addition of new functionality.