SOUND : An Effective Coding and Code Review Technique

Coding and Code review are the most basic building blocks of any software product. Any lapse may severely affect the schedule, quality, and of course the cost. Not only in the review but a few issues can also be found at a later stage as well. That may lead to rework.

With my experience of over a decade in this, I have grouped relevant Non-Functional requirements logically and call it SOUND. I use them and recommend to make it an integral part of the coding and code review process.

Before I start, some important points to note –

1. It is repackaging of coding and code review techniques so that they can be done more effectively.
2. Concepts shown here are just for a guideline. They can be changed based on the actual requirement, technology stacks, standards, target user. 
3. This article is about What to do NOT How to do,  and NOT specific to any technology platform, hence it has no code example or any technical demos.
4. Though majorly I have included Non Functional requirements, it does not jeopardize Functional requirement at any point of time. 

What is the SOUND?

It stands for –

• S – Secure Programming
• O – Optimized Programming
• U – Useful Programming
• N – Neat Programming
• D – Defensive Programming

S for Secure Programming –

What is Secure Programming?

Yes, it is related to the security of the application or your unit of assignment. We agree that we can not make our code 100% secure still we can prevent it from most vulnerable attacks. It has the objective of having a reliable and robust software product.

Sometimes secure programming is not considered because of laziness or programmer, strict timelines to complete, less knowledge of security threats.

How we can do Secure Programming?

Under Secure programming, as a developer, we need to understand all the security threats. For this purpose, the best approach to follow OWASP ( OWASP (Open Web Application Security Project ) Top 10 threats. Here is a brief introduction to them and we will be covering them in subsequent articles.

• Injection Attack – It occurs when untrusted data is sent to an interpreter as part of a command or query. (All about SQL Injection attack Read here)
• Broken Authentication – To exploit the flawed authentication mechanism implementation. (Read here all about Broken Authentication )
• Sensitive Data Exposure – Many application and API do not protect secure and sensitive data. What is this and how to prevent this?
• XML External Entities – Flawed XML used for internal information.
• Broken Access Control – Not implementing the right authorization in the application.
• Security Misconfiguration – This is a consequence of default configuration, misconfigured HTTP Headers and verbose.
• Cross Site Scripting – This allows the user to execute script in a victim’s browser to hijack user sessions, deface a website or redirect the user to a malicious website.
• Insecure Deserialization – This can lead to remote code execution based on vulnerability.
• Using Components with unknown Vulnerabilities – Many libraries, frameworks, and other components run in the same privilege as the application. if those components have any security vulnerability then an application can be easily exploited.
• Insufficient Logging and Monitoring – Mainly in integration with other systems, we need to do proper monitoring as it may provide a gateway to the attacker.

O for Optimized Programming –

What is Optimized Programming

Optimized programming leads to an efficient software product, less input-output operations, faster execution, less memory consumption.

How we can do Optimized Programming?

• Language-specific best Practices should be followed.
• Use of unnecessary boxing and unboxing should be avoided.
• Use of string builder should be preferred over string for concatenation.
• Caching should be used diligently as over caching may create further issues.
• Lazy loading and instantiation should be preferred.
• Memory leak, garbage collection etc should be handled efficiently
• Threading should be optimized.
• The appropriate type of collection should always be used.
• Reflection should be avoided unless it is needed.
• Database design and queries should be tuned.
• All the time normalization of DB tables only should not be considered, sometimes it is better to have denormalized table.
• Use compression, minification and bundling concepts for JavaScript, CSS and other static web resources.
• Only needed fields of the class should be serialized.

U for Useful Programming –

What is Useful Programming?

It means our program should be useful in terms of testability, maintainability, extensibility,  Modifiable, and scalability. Scalability is an engineering problem and depends heavily on architecture followed. Extensibility is 

How we can do Useful Programming?

• Follow SOLID principles for class designing.
• Implement design patterns for your assignment.
• Adherence to application standard architecture.
• High cohesion and low coupling.
• For web farms and Web Garden, a session should be managed out of process either in SQL Server or State Server.
• Proper indexing strategies should be followed.
• The concept of parallelism should be implemented. 
• Choose wisely between inheritance and polymorphism. 
• Database schema should be designed in a way that requires No/minimal changes in the future.

N for Neat Programming –

What is Neat Programming

The code is read 10 times more than it is changed. So, our code has to be easy to understand and change. Subsequently, it helps in reducing maintenance and enhancement cost of the software product.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

How we can do Neat Programming?

• All variable names should be self-explanatory and follow the standard.
• The class name should be a noun while the method name should be a verb.
• Proper XML commenting needed by many tools (e.g. Sandcastle) to generate Technical documentation.
• Try to add Modification History in code files to track and refer to the changes in the future.
• Try to make method body as small as possible because big methods prevent the process of debugging, understanding business rules, optimization, and refactoring.
• Big methods also have more probability to change.
• If it is not possible to keep class size small, use the concept of partial classes to logically group the functionalities. 
• Follow naming convention for DB objects as well by avoiding system defined keywords.
• Apply these concepts whenever they are applicable –
  • SLAP (Single Level of Abstraction Principle) – according to this, a function should be doing one specific task.
  • YAGNI – (You Are not Gonna Need It) – Don’t make system unnecessarily complex.
  • KISS – (Keep It Simple Stupid) – It covers proper indentation, formatting of written easily understandable code.
  • DRY (Don’t Repeat Yourself) – In order to keep application code clean, don’t write redundant codes.
  • GRASP (General Responsibility Assignment Software Patterns) – Identification of the responsibilities of classes and methods clearly and there MUST NOT be any duplicity.
  • The Hollywood Principle – Implementation of “Don’t call us, we will call you” approach in designing API and Framework.

D for Defensive Programming –

What is Defensive Programming

Defensive Programming provides us high availability of code, high quality, safe and smooth execution of the application, robust, less bug etc. Without defensive programming code runs in normal condition/ input but will break with the deviation.

How we can do Defensive Programming?

• Don’t trust even your code, do a proper null reference check.
• Assume a user can make any mistake hence handle that, do proper exception handling.
• Be prepared for unexpected inputs and user actions.
• Each input parameter of the method should be validated before processing.
• For web applications, apply client-side and server-side validation both.
• Having default in the switch case, else in an if-elseif loop is also defensive programming.
• Write and perform rigorous unit testing.

Conclusion –

This statement will clear all doubts (if any) for categorizing non-functional requirements under SOUND

Secure programming is to save from attack while Defensive programming is intended to handle unexpected user inputs or actions. The Neat programming is somehow like clean code which in turn talks about the readability of code while Useful Programming covers scalability, maintainability, extensibility, and testability. Optimized Programming means code performance should be best at any time while scalability under Useful Programming refers to the ability of software product to function well with increased demand condition and remains stable.