Ubuntu insights, Programming in groovy, java, et als!

Wednesday, July 06, 2011

Programming Practices for the Corporate Developer

'A mediocre level in coding and proficiency in a programming language would suffice to develop an application'

Well, that was my mindset just post completion of my under graduation. Fortunately, it was blatantly proven wrong soon after I set foot into the corporate world. Technically, knowledge in programming is all one needs to develop a software application but in the corporate world, I've learned lately that the style of programming adapted is of more importance than that of programming itself. Here are few programming practices that are expected to be adapted by a software developer in the corporate world.

Design patterns

Perhaps the most important of all the programming practices is to strictly adhere to the standard design patterns available. We often come across such scenarios in the world of Object Oriented Programming where in multiple instance creation is a necessary operation yet it tremendously slows down the performance of the application. This is where design patterns come to rescue. For ex: Adapting a singleton design pattern would restrict the deliberate creation of unnecessary instances of an object. On the other hand adapting a design pattern like factory would efficiently handle multiple instances of an object that are too many yet necessary, so that selecting the appropriate instance of the same from the factory would be a lot easier than manually keeping track of the multiple instances. A programmer can always create his/her own design patterns too, adhering to which the re-usability can be exploited to the maximum enabling better performance of the application developed.

Naming Conventions

Naming conventions when considered petty or trivial can certainly lead to headaches while developing an application especially when there is scope for extensibility. A programmer must always be sensible enough to follow naming conventions, after all, he/she is not the only one dealing with the same piece of code in the corporate world. For example: Take a look at the creation of a java swing button with the name string 'Okay'.

JButton b = new JButton("Okay") //You suck buddy!!
JButton button = new JButton("Okay") //Duh!!! WTF ???
JButton okayButton = new JButton("Okay") // Hmm. Better!!

Hope it is clear from the above example! Never ever follow senseless or vague naming conventions. Nevertheless, a good piece of code will always be understood by any other programmer where as a bad code will never be.

Constant Refactoring

An application when developed from scratch starts off with a minimal set of classes and packages and it often grows so huge that it would be so damn difficult to manage the growing size and added functionality. So a programmer must make sure that the piece of code written must be made reusable to the maximum extent possible so that it can be further used again. Splitting up functionality into miniscule atomic functions specific to need would help a tonne. Further growing number of functions can again be refactored to different classes when one particular class gets cluttered with too many functions. And one level above, growing number of classes can further be split up under packages. Such constant refactoring code would make it easy for a programmer to rope in additional functional components and also the refactored code could be reused as well.

Ease of the programming vs performance of the application

Software applications when developed on dynamic languages are often susceptible to performance issues when the programming is deliberately done ineffective by a lazy programmer. For example: High end programming languages support dynamic binding that also adds to the ease of coding for a programmer. In one such instance, a programmer always has a choice to deliberately ignore mentioning the return type of a function so that it could be determined at run time later on. Such lazy programming practices can prove costly and lead to performance issues on a large scale considering the method's overall implementation. So a programmer must be intelligent enough to exploit the power of programming but never at the cost of the application's performance.

Considering that my experience in the IT industry is too less to talk more about better programming practices, the above are few things that the corporate world had taught me in the last couple of months. Hope that these few would help peers and the readers of this blog to code better in the corporate world.


Post a Comment