Written by: John Maruschak, Senior Developer
Our Concept of Programming
When deciding what technologies to use in a new project, it is most important to determine the broad strokes of the end result. What should the project accomplish when it is complete? Is this a new module to complement an existing software package or is this a brand new software package that should be accessible only to your work force? We believe that there is an enormous amount of value in meeting with our clients face to face. These face to face meetings allow us to gain a thorough understanding of the goals of our clients and to determine the best way to proceed. Early on in this process is when we can start making decisions on what type of project we are dealing with. This then determines what technologies we are going to employ and helps to facilitate future meetings by providing us a framework to start thinking about the project in a more granular and specific way.
So, with so many different programming languages, across so many different platforms, what makes a program “good”? This is also a slightly ambiguous question, as there are a wide variety of programming styles. Ultimately, the primary concern for any developer needs to be to make a program function the way that a client requests and it could be argued that any program that does so is “good”. However, there are a couple of factors independent of the tools chosen that can separate a program that merely functions correctly from a program that functions correctly and does it in the most elegant way possible. These functions include code readability, error handling, and re-usability.
Programming Code Readability
Code readability may seem fairly obvious since code should be written in a way that allows any developer to quickly gain an understanding of what the code is trying to accomplish. In my experience, this has more to do with consistency than anything else. There are sometimes official recommendations that go along with a specific language for things like bracketing and variable naming, but as long as a developer sticks to a specific and reasonable way of spacing and naming within his or her code then any competent developer can dive into the code and not feel lost. This is important because of the oft used hypothetical scenario, what if the initial developer is hit by a bus and another developer needs to pick up the work where it was left off. We like to use “wins the lottery” instead of “is hit by a bus” since we are usually the programmers being referred to.
A method for handling errors is built into most languages. Programs can consist of under 100 lines of code, to millions of lines of code depending on the application. In most cases, each line of code has one or more scenarios where it can fail, and possibly crash the application. It is the developer’s job to foresee as many of these scenarios as possible, and to plan for them with error handling. Error handling should capture the known errors and give the user info on why the current line failed. After the user has been informed, the application should continue running seamlessly. Now, asking a developer to foresee every scenario, where every line of code can fail, in an application that consists of millions of lines of code is unreasonable. This is why most error handling has the capability of handling unforeseen errors as well. In these cases, the program should be set up in such a way that the error is caught and the application continues running. If possible, the program should automatically notify the developers and any other relevant parties of the error that occurred so that the situation can be dealt with appropriately. In all cases, the user’s activity should not be interrupted for anything within the developer’s control.
When I refer to re-usability, what I am really talking about is accomplishing the most programming tasks possible with the least amount of code, which may be the most important of the three factors that I have mentioned. A developer should never repeat code unless it is absolutely necessary. There are several different benefits of this approach from both a developer’s perspective, and a client’s perspective, all of which have to do with time. Taking the time to write a tool that will then be used in multiple areas of a software package reduces the amount of time it will take to implement those other areas. It also makes error handling, debugging and added functionality exponentially easier, as the developer will only need to examine and modify the tool if anything arises. Code readability, then, is also increased for the same reason.
VantageOne Software is a leading onshore software development provider offering web, mobile and enterprise-level custom software and application services. For more than 20 years, our teams have used their technical expertise and in-depth domain knowledge to streamline organization’s operations for optimal success — a real competitive advantage. Certified as a Women’s Business Enterprise (WBE) through NEORSD and WBENC.