Programming is the building block of any website. The program should be secure and foolproof for the information to be safe. Bugs in programming pave the way for hackers, who may compromise your database. This may lead to loss of valuable information or even a complete system failure. We will discuss some of the horrors that can pop up in programming.
Programmers should be experts in practical coding, not just theory. While some knowledge is obviously needed, it is not enough. You may have come across people who are good at syntax. When it comes to writing the code, the so-called bogus experts may not be the best. You can see some programming horrors as you read on.
The rogue administrator
Let's start the list off with a bang! When it comes to selecting an IT administrator, you have to be careful. Otherwise, the results might be drastic.
There was an administrator who built an infrastructure that demanded at least 50 hours a week from everyone to support. He did it intentionally. Every machine in the building had been programmed by himself and a ... well let's just say, an acquaintance with equally maleficent intentions. The mailing system he had put together allowed him backdoor access to every email that came through. At times, he deleted some data, and even framed another employee, resulting in him being fired.
The management blindly believed in him as he installed a bogus accounting software. He used gibberish variable names while keeping private lookup charts that helped him remember the function of each variable. The management overlooked the complaints about him, mistaking it simply because he was otherwise, apparently, so bright.
He was indeed a computer genius, but with evil intentions. The management should be cautious about such employees. Proper HR can prevent such horrors with good referencing and interview procedures.
Handling overqualified seniors
Perhaps less troublesome than the previous scenario, there can be bad blood between project members if proper communication is missing. Some developers having a Ph.D. in an unrelated field may have less practical knowledge compared to a graduate in the relevant field. The former may be a computer genius, in many respects, but different languages need different expertise.
The acknowledged expert may go through complex paths and prolong the project. What could be completed in a year may extend to three years or more. The required changes in the project should be properly conveyed. You should remember there will always be someone in the industry who has a better solution than you. That is the reason why projects are handled by teams and not individuals.
The junior members should be careful not to step on the toes of the seniors - many of them after all have experience to be taken into account. Seniors may intentionally hinder your progress if tactical approaches are not made. Your solution may be elegant, but it should be presented in the right way.
We all have to be diplomatic to go a long way in our careers.
Outsourcing gone bad
At times, you cannot do an application or project with your in-house resources. That’s when you go for outsourcing. This is a critical step that should be meticulously planned. The consultant’s code may be smarter than our database code. But the compatibility with our systems should not become an issue in the future.
Success is best enjoyed when it is the result of long hard work. So while going for outsourcing, be careful about the confidentiality of your data. There are instances where the outsourced project was leaked to the competitor and the company incurred huge losses as a result. The industry is cunning and waiting to exploit you. Don’t fall into the trap!
Programming mistakes
Indentation
Proper indentation is a crucial part in making your program readable. Consider the following code fragments:
Code 1
For(a=0;i<10;a++)
{
For(b=0;b<10;b++)
{
For(c=0;c<10;c++)
{
For(d=0;d<10;d++)
{
C(d)++;
))))
Code 2
For(a=0;a<10;a++)
{
For(b=0;b<10;b++)
{
For(c=0;c<10;c++)
{
For(d=0;d<10;d++)
{
C(d)++;
)
)
)
)
The 2nd code is obviously easier to read. This can be so helpful in the case of lengthy codes. The use of indents enhances your program’s readability. It makes it easy to debug also. It can be a nightmare to debug a lengthy code where no indentations are used.
Choosing variable names
Giving meaningful names to your variables can be extremely helpful. For example, if you are working on a calendar related project, give variable names such as day, month, year, etc. Rather than using xyz, using meaningful names can prove useful in the long run. Short variable names may seem a good choice at the beginning, but as the number of variables increases, you will appreciate this practice.
Another habit is the use of look-up tables. In the case of hundreds of variables, the programmer cannot remember the function of each and every variable. In such situations, look-up tables come to the rescue.
Using GOTO
Many years ago, the use of goto was a favourite option for programmers, if they wanted to create a loop or jump to another routine. Goto is followed by the intended line number. After a few years, programmers were advised to use a string label instead of a line number.
This sometimes resulted in a confusing code. Labels became difficult to find. It makes your program difficult to read. If not carefully executed, it can even lead to infinite loops. Stating these reasons, the use of goto was prohibited later.
A carefully put break or return statement can sometimes do the job more cleanly. If-else cascading may be bulkier. Goto statements can sometimes handle it more efficiently.
But some examples clearly are against goto. The "goto fail" security hole that occurred in Apple's SSL stack is one of them. However, if we're careful to avoid some of the awful issues of statements and loops, goto statements can be good alternatives. Nevertheless, care should be taken if you decide on using goto.
Unwanted documentation
Documentation can be thought of as comments to help readers understand. Function names, if properly chosen, can be self-explanatory. For example, names like addmember, deleterows etc. need no further explanation. Choosing the right names can help in reducing the comments and improve readability. In some cases, it proves better than writing long documentation. Functions may occur at more than one place, whereas documentation has only a single instance.
There may even be cases where documentation can lead to misunderstandings. If the code gets revised multiple times, the associated documentation need not be revised. This can become a serious issue. Proper care should be taken in these cases. The codes and the documentation should never diverge.
Evidently, self-documentation is better than comments in most cases.
Proper declaration of types
You should declare the type of variables you use in the program since it can avoid many bugs. If a number variable is not declared, it may cause confusion in the minds of the reader. It may be integer or float. So, be clear and specify your variables.
All programmers may not correctly identify the type you had intended for a variable, but in some cases, as in a loop incrementer variable, that variable will be an integer. This may not be the case all the time. To be on the safe side, always declare your integer types. It will also ensure proper memory allocation, which can be of great help when programs need to be revised.
So these are some of the less desirable scenarios that have happened - or could happen - to programmers. Learn from these stories, enjoy programming and stay out of trouble! Let us know in the comments below if you have any interesting or even scary stories that the community could enjoy and take note of!
