Tuesday, 3 January 2017

Top 5 bad coding practices that could wreck a software development project

For software developers today, it is always good to determine some bad coding practices so as not to make these mistakes repeatedly. In any coding job, the best practices are a set of informal rules that the software development community learned which could boost program quality. Many computer programs remain useful for longer than the original authors have imagined, some up to forty years even or more. Thus, any rule or rules should facilitate initial development and improvement as well as maintenance by people, aside from the original makers.


1. Typos in the code are common and quite frustrating because they have nothing to do with the programming skills of the developer. Regardless, a misspelled name or function can wreak havoc on cryptogram. Moreover, they may be hard to see. A solution would be to work in a good IDE or integrated development environment or a programmer-centered text editor that could considerably minimize errors. Another way is to choose a function and variable names intentionally that could be easily spelled and so easy to spot if misspelled.

2. Sensitive content should be encrypted as it travels over a network. This is because the data is vulnerable to interception when it does. This is not only a great idea, but a regulatory requirement as well. This means that sending data in the clear is a big no. Writing one's encryption system is hard, so it is important to utilize a proven industry standard encryption library and use it in the correct manner.

3. One bad coding practice is the failure to modularize cryptogram. It is a good practice to write functions that do one thing and only that alone. This helps to keep them short and thus, easy to understand and maintain. Long functions have many possible paths through them, making them more difficult to test. A good rule of thumb will be that a single functionality should occupy no more than one screen. Another is it has ten or more 'if' statements or loops, then it would be too complicated and should be written again.

4. Formatting and indenting code makes it easier to understand at a glance and to see errors. If a developer fails to do this, then the harder it will be. Furthermore, it also makes it so much easier for others to maintain code, as it is presented consistently. When using an IDE which does not automatically format, it would be a good idea to run it through a beautifier such as Uncrustify. It will consistently format based on the rules configured.

5. It is tempting to hardcore a secret password and account so one can get into the system later. However, this is considered a bad practice. While it is very convenient, it is also highly convenient for those who access the source cipher. The true issues is that eventually, a hardcore password will be more widely known than it was intended to in the first place. This could be a huge security risk, not to mention a very inconvenient option. 

It is bad for a developer not to think ahead when it comes to developing software solutions. One should think things ahead, including what the project is for, how much the scale is expected, the number of users it will have and how fast it runs. The answers may not be available, but if a developer is not able to do estimates, then it's impossible to choose a suitable framework for developing an application that will meet the requirements.

No comments:

Post a Comment