Book a Free Consultation

Bad practices in programming

Bad practices in programming

Bad practices in programming

As it is in every area, also in programming, there are good and bad practices. When focusing on the latter, it’s worth not only to specify what they are, but most importantly to define them. Bad practices are those that make the code difficult to understand for the other team members and require an extensive analysis, which in result makes maintaining the app harder.

Every programming project is characterized by a dynamic life cycle – apps undergo constant optimization later also expansion with new functionalities, which come in handy with time, change of expectations or market trends. In addition, growing popularity of scattered teams and lack of direct contact between team members requires not only code of the highest quality, but also legibility. In this article you will find out what to avoid while developing software, for your code to be not only good, but also easy to understand.

Ineligible terminology

Names of variables and functions should be descriptive and understandable not only for you. Using to much obscure abbreviations you could make the code ineligible for everyone except you. A programmer that is new to the project wouldn’t know what you meant and code analysis without legible nomenclature of, for example, functions will take ages. You have to make sure that the names are descriptive and clear, so that can easily understand them.

Excessively complicated code

Creating more complicated lines and complex commands than it is necessary, not only makes them hard to understand for other team members, but also makes it difficult to overwrite further functions in the future. Your code should not be overly complicated, so that it can be maintained and developed in the future. Remember that it is meant to be used to create stable, compatible and comprehensible. Make sure your code is high quality but also sufficient. IT projects have to comply with quality and safety standards. But at the same time they’re not a place for complicated and obscure commands, although showing advanced skills of the programmer, but also making the hard to understand for the other team members. Make sure your code is sufficient – high quality but simple enough to be understood by others.

Correlations

When creating additional files – for example header files, which include function prototypes and allow to write big applications, make sure you place them in logical places, so other people can easily find them. Focus on legibility and order. It’s a good idea to create a separate catalogue, where you can store, for example all the files concerning payments,  and not creating files as you go. Not only will it make the code easier to understand, but it will be also easier to find your way around the structure of the app in the future, when some changes are applied. Take care of order and logical structure of the whole project.

Differences in operation

Cohesion and predictability are a key to every project – they have a direct impact on mutual understanding of individual elements and final compatibility of the whole project. One of the worst practices is creating the same functions and giving them different working patterns. If your functions are the same, but they behave a little differently in the code, take a look at the wireframe of the project and make some unifications. Don’t treat functions selectively – they should work the same way in the whole project. Only unified and predictable interfaces make work effective.

Copy and paste

Another bad programming practice is copying the code. Not only you lose certainty that your code will work well, but you also force other team members to update multiple files while applying changes. Remember not to copy similar fragments of the code senselessly, because you can’t be sure if they will work correctly in other place.

You don’t create code for yourself

Remember about the core principle of project cooperation – you should write your code, so that the next programmer who joins the project will understand it. Try to walk in their shoes and imagine their way of thinking. Consider whether after a few months of you not seeing the project it will still be comprehensible for you. So to summarize, take care that the code you create is objectively understandable.

Leave a Comment

Your email address will not be published.

Facebook
LinkedIn