Common Bad Programming practices

Everyone learns with time and to your surprise programmers are no different. We (Yes Programmers) make mistakes and promise ourselves we will not repeat again. We repeat again and promise again. And the day comes, we don’t repeat that mistake. That day we feel satisfied and drink that cuppa with internal sense of completeness.

But we are here to discuss some bad practices (in my opinion) which make me feel sick whenever I encounter them. Everyone has his own style of programming but these few IMO really needs attention. There could be many others as well and it is possible that I am the only one who does not like them. In any of the case do not loose your temper and curse me while driving and never forget that tobacco is bad of health.

Practice 1 — Negation If with else

If(not_condition) { 
//do task with no_true
} else {
//do task with true
}

Example :

If( ! (age >=60)) { // negation ! your mind will hate this statement
 print(“You might live some years”);
} else {
print(”You might die any moment!”)
}

I read such If statement in code many a times and it makes my mind stop for a moment. Because it is not usual, it is not simple. Something which could be expressed easily but writer (programmer here) preferred unusual and irritating(IMO) way because he had a bad day.

Else clause by definition is for negation of statement and it adds less burden on mind to understand.

Want something Simple :-

if(age < 60){ // affirmative condition
 print(“You might live some years”);
} else {
print(”You might die any moment!”)
}

Practice 2 — boolean condition to return boolean

Compact code is always easy to understand. But most programmers make this mistake in their early career many a times. See this :

Version 1 (Very irritating) -

boolean isTeenager(int age) {
boolean isTeenage = false;
if(age < 20 && age > 12) {
isTeenage = true;
} else {
isTeenage = false;
}
return isTeenage;
}

Version 2 (Irritating) -

boolean isTeenager(int age) {
if(age < 20 && age > 12) {
return true;
} else {
return false;
}
}

Version 3 (I love it) -

boolean isTeenager(int age) {
return age >12 && age <20; 
}
YES WE COULD replace those numbers with constants (MIN_AGE_FOR_TEEN and MAX_AGE_FOR_TEEN) but you know what this definition wont change and do not be over-smart here. Excess of anything is bad. Again in IMO.

Writing code is an art iff your code can speak on your behalf.

Practice 3 — Continuous if with no family relation

I see sometimes this type of code (99.9999% with no comments) and believe me it makes me wish If I could meet this programmer while I am all drunk and hit him with that empty beer bottle. Here I present lovely piece of code :

If(some_condition_to_check_interest_rate_in_Bank) {

} else if(some_condition_to_check_free_meal_in_restaurant) {

} else if(some_condition_to_check_earth_is_round_or_not){

} else if(some_condition_from_other_universe_which_can_never_fit_with_others){

}

I am not saying this situation is not practical but if it is, please on God’s name write a good comment where other can refer your business logic. Don’t make them hate programming and specially your kids.

Practice 4— The If Lover with all code in between

Compact code -> Readable code -> Maintainable Code -> Lovely Code

But few programmers hate being lovely. They think If I am doing this shitty job why shall I make others life happy. They give their best to make others day as bad as possible.

Remember: When you write bad code in x hours, you waste 2x + c time for maintainer where c is undefined and he will definitely curse you more than his wife. If someday something bad happens to you in future, think it is because of one frustrated programmer who tried to jump in your codebase.

See this :

if(some_condition_1) {
// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort
} else (condition_2) {
// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort

// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort
} else (condition_3) {
// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort

// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort
}…



if(condition_51){
// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort

// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort

// some line of code which could have been called as function
// but no our beloved programmer thought it will be hard
// for him to put 0.01 millisecond of extra effort
}

Use functions and switch statement wherever you can, readability of code is more important than what you ate in lunch.

if( condition_1 ) {
callFunction();
} else if( condition_2 ) {
callFunction2();
}

See how easy it is to read, maintainer will still curse you but believe me you can manage this. Remember “Karma” is always watching.

Practice 5— The Mysterious Return

I am sure you must have seen code where programmer thinks it will save some energy and carbohydrates if he returns immediately. Check this out :

line 168 : // some code here
// some code here again which will for-sure throw null pointer with one mistake
line 237 :// some code here again which is error prone
// if (condition1) {return;}
// some code here again
// some code here again which looks good //
 if(condition_2){ return;}
// some code here again which somehow manages to executes
line 301: // some code here again which is well though
// return properly

Do you see those two mysterious returns in between. Read again if you missed. Suppose a new programmer comes and that poor soul wants to write a simple log OR analytics event. He adds his beautifully crafted line at end and drank his coffee and closes his eyes with a dream of driving Ferrari one day. He ships his code but later on gets to know about your mysterious return which f***ked up his whole analytics. How can you think he will not pray for you being dead. Peace!

There could be many other bad code practices OR it is also possible you support one of these. Comment your opinion and lets have healthy discussion. Don’t be a “**ck” → a sick person I meant.

Found this post useful? Tap the ❤ button below! :) If you won’t; Remember Karma!