Good Programming Practices in General

Object on need:
Avoid creating object when we yet to realize actual need. Object creation is the 
overhead. It consumes the memory space also. Longer is the time, object keeps consuming memory thus, less is the space available for other vital objects. Thus create objects lazily, initialize lazily only when it is needed in the code.

Don’t assume output formats:
There are different formats and Medias to present the output. The data may be output to screen, printed to printer, logged to loggers, persisted to database, presented in HTML format to internet user or presented in XML format to another system. The low level functions return values in basic format for caller to decide the presentation.

Operations on object:
Instead of passing complex data structures across functions, operate on objects which are encapsulated with data structure and data accessing functionalities. Such objects hide data formats and gives simple abstraction for accessing data. eg: you can use BankList which encapsulate ArrayList which in-turn encapsulate Accounts objects.

Open close principle:
       Software entities should be open for extension but close for modifications.
       Design the code and classes such a way that nobody need to open code to do modifications but new behavior could be made possible through extension.

Avoid pre-mature optimization: It is a root of all evils. 80% of code becomes 
in-efficient because of 20% culprit code.

          Think of optimization only when software go slow. Identify the culprit code and fix it  
         for efficiency. The efficiency and simplicity are enemies of each other

Prefer interfaces over abstract classes: 
         It’s very easy to change implementation of a class or add new implementation for a new interface rather than changing hierarchy in case of abstract class. Although, any change in an interface breaks the code of implementing class while that’s not the case with abstract class

Avoid declaring class as final:
         Declaring class as final (as a collection of final type methods) is an extreme measure.
         Instead, declare methods as final. A final class gets blocked for future modification forever in inheritance tree. While designing a class for all final method, design all methods as final so that in future, If this class is to be augmented by new final methods, it can be done in sub-classes.

String concatenation:
        If strings are concatenated within for loop will lead to creation of an object everytime.
        Such string handling should be done using StringBuffer. 
        Also, string creation using constructor is slow compared to assigning string literal to the string reference.
                                a. String a = new String(“Message”); // It is slow
                                b. String a = “Message”; // It is fast

Using Singleton for service classes:
        The entity specific classes need to be instantiated for every entity while for service classes, one instance should be created and shared across whole code of the application. This will lead to prevention of unnecessary object creation thus conserving heap memory and effort of Garbage collector.

Their are more such practices to reveal, I will soon Post it. Thanks :-)

Comments

Post a Comment

Popular posts from this blog

Hashicorp Configuration Language - HCL

Installing Terraform What is Terraform and Why do we need it? Terraform Commands Here, we will cover the basics of the Terraform configuration language, as well as explore providers and resources. Continuing what we started in Terraform Commands, we will modify main.tf so we can deploy a Ghost container to Docker. The syntax of Terraform configurations is called HashiCorp Configuration Language (HCL). It is meant to strike a balance between being human-readable and editable, and being machine-friendly. For machine-friendliness, Terraform can also read JSON configurations. For general Terraform configurations, however, we recommend using the HCL Terraform syntax. Terraform code files The Terraform language uses configuration files that are named with the .tf file extension. There is also a JSON-based variant of the language that is named with the .tf.json file extension. Terraform Syntax Here is an example of Terraform's HCL syntax: resource "aws_instance" "example...
Read more

Terraform - Input Variables

Installing Terraform What is Terraform and Why do we need it? Terraform Commands Hashicorp Configuration Language - HCL Tainting and Untainting Resources Terraform Console and Output Input variables serve as parameters for a Terraform file. A variable block configures a single input variable for a Terraform module. Each block declares a single variable. Syntax: variable [NAME] {   [OPTION] = "[VALUE]" } Arguments Within the block body (between { }) is configuration for the variable, which accepts the following arguments: type (Optional): If set, this defines the type of the variable. Valid values are string, list, and map. default (Optional): This sets a default value for the variable. If no default is provided, Terraform will raise an error if a value is not provided by the caller. description (Optional): A human-friendly description for the variable. Using variables during an apply: terraform apply -var 'foo=bar' Set up the environment: cd terraform/basics Edit main...
Read more

Terraform - Tainting and Updating Resources

Installing Terraform What is Terraform and Why do we need it? Terraform Commands Hashicorp Configuration Language - HCL We are going to take a look at how to force a redeploy of resources using tainting. This is an extremely useful skill for when parts of a deployment need to be modified. Tainting and Untainting Resources Terraform commands: taint: Manually mark a resource for recreation  untaint: Manually unmark a resource as tainted Tainting a resource: terraform taint [NAME] Untainting a resource: terraform untaint [NAME] Set up the environment: cd terraform/basics Redeploy the Ghost image: terraform apply Taint the Ghost blog resource: terraform taint docker_container.container_id See what will be changed: terraform plan Remove the taint on the Ghost blog resource: terraform untaint docker_container.container_id Verity that the Ghost blog resource is untainted: terraform plan Updating Resources Let's edit main.tf and change the image to ghost:alpine. Open main.tf: vi main.tf ma...
Read more