Adaptive Software Solutions

The standard naming convention for classes in Java is to write the class name in InitCaps. So a class which denotes the customer sales record should be named CustomerSalesRecord This format makes the name easily readable. We should be careful to chose a name which clearly describes the purpose of the class. Try to avoid short forms or acronyms unless they are clear enough, or if using the full name makes the class name way too long. What exactly constitutes way too long is an individual choice. I would say over 50 characters is long.

Yesterday I said that it is a very good practice for a software developement team to follow coding standadrds. I have often been asked, "why is it important?". The primary reason is that following standards makes the program more readable, and hence more maintainable. More often than not, software is maintained by a different set of people than the ones who created it. If all programs adhere to standard coding conventions then the maintainers will be able to find what they need quicker and understand the program better. Eventually it translates into lesser hours spent for bug fixes and enhancements.

A few days back I was reading an article on Coding Standards. There are a few articles and even books available on this topic. Following coding standards consistently, I believe is very important for a software development team. Coding standards are not written in stone. They are guidelines for making software code more readable. Like most guidelines they can be, and usually are customized for individual teams. Most teams have well defined ways in which they structure their code and name variables, methods, classes, etc. The specific standard a team adopts is not as important as the practice of ensuring that the entire team adheres to the same standard.

As system architects we have to foresee things that can change in the software specification over time. We have learned that a good system design is one that seperates the things that change from the things that do not. However in trying to foresee potential changes we often try to design for changes that may not happen. This leads to an over-engineered design which is more time consuming to implement and difficult to understand. Such a design becomes counter productive. While designing a software it is important to view the changes we anticipate along with their probablity of occurence. It is often a good idea not to design for a low probability change, if it significantly increases the design complexity.

As system architects we have to foresee things that can change in the software specification over time. We have learned that a good system design is one that seperates the things that change from the things that do not. However in trying to foresee potential changes we often try to design for changes that may not happen. This leads to an over-engineered design which is more time consuming to implement and difficult to understand. Such a design becomes counter productive. While designing a software it is important to view the changes we anticipate along with their probablity of occurence. It is often a good idea not to design for a low probability change, if it significantly increases the design complexity.