Bad Code

Read about good coding practices, and understand the arguments for why they're good practices.

Read about bad coding practices, and understand the arguments for why they're bad practices.

Then, write code as best you can, and lots of it. In fact, starting out, I'd almost recommend to favor quantity of code over quality -- don't write code that's artificially bad just to crank out more of it, but my point is that no matter how much you read about good and bad code, your early code will fall more into the "bad code" camp than the "good code" one.

Often times, the best way to understand and internalize what "bad code" is, is having written it and experiencing why its painful first-hand. When you've experienced the pain of bad code, you begin to get a sense of what it feels like--a gut feeling--and you will start to instinctually avoid writing it. In this way, you continually move the ball further down the field.

You can think of it like American football--when the kickoff is recieved, the team first works toward being in a position that's less-bad until they reach mid-field, then they work toward being in a position that's more-good, if you follow me. On their own side of the field, they're at a disadvantage that they just have to keep chipping away at, but once they cross mid-field they're no longer in the weaker position, but they're still working toward the goal. Learning how to do anything well is like that, except that in learning, unlike football, you always start on your own 10-yard line and there are no hail-marys.

Are you coding by yourself or in a team? I used to have the same worries you do, then I realized that I'm the only person who works on my code so who cares? The end result is all that matters for me. Of course, I don't know what type of code you are writing. I use a game engine and how I write my code makes little difference to the performance.

Hey,

Thanks for the quick response.

I understand that writing alot of code will help at seeing whats good and bad code. But won't some bad practices stay? As I don't see if its bad or good so I will keep doing it the bad way. I guess thats one of my biggest fears of bad habits getting stuck.

Are you coding by yourself or in a team? I used to have the same worries you do, then I realized that I'm the only person who works on my code so who cares?

I'm coding alone and in a team. I'm studying computer science and last time I worked in a team I felt that I was among the weaker coders so I want to change that. So I'll also code for my job later on, or thats the plan atleast. This may not be coding games but still.

Thanks again for the repsonses

Cenox

Thanks for the answers!

Seems like I need to worry a little less and code alot more, hehe! Which I will do.

Thanks again, it helped me alot.

Hey,

Thanks for the quick response.

I understand that writing alot of code will help at seeing whats good and bad code. But won't some bad practices stay? As I don't see if its bad or good so I will keep doing it the bad way. I guess thats one of my biggest fears of bad habits getting stuck.

Are you coding by yourself or in a team? I used to have the same worries you do, then I realized that I'm the only person who works on my code so who cares?

I'm coding alone and in a team. I'm studying computer science and last time I worked in a team I felt that I was among the weaker coders so I want to change that. So I'll also code for my job later on, or thats the plan atleast. This may not be coding games but still.

Thanks again for the repsonses
Cenox

Don't get me wrong but you always feel like that. Even experienced and senior programmers feel this way and it comes more from the fact that you can't know everything than anything else.

When I look at code I wrote 5 years ago I go this is atrocious, bad application design and even implementation is wanting, but I can also see how much I have learned over the years and that boosts my confidence.

One tip write code that works, getting the job done is more important then writing extremely clean code. Code that gets the job done isn't always clean but it should be readable. If you notice yourself reading code you wrote a month ago and completely not understanding it after 15 minutes then that is a sign of bad code.

Over the 6-7 years I have worked now I have seen code that goes from alright that looks clean to extremely horrible code. The worst examples I have seen so far is reinventing inheritance with templates. Another one is a class that only has static members and methods and represents a game state.

One of the best comments I have found in a code base is "Ow, magic numbers guide us to the light!" on the declaration of a constant.

Knowing you have some bad code is important, learning to admit it and live with it till the appropriate time, that's a serious skill. What really matters is dirty or not, it functions and gets the job done first. I usually go with a rule (think this is from agile or something) that I'll ignore things for a bit and the first time I have to fix a bug, modify a piece of dirty/bad code I'll make a note of it, the second time I touch that code, I go back and tag it for refactoring. Every week or whenever my list of todo's gets too big, I spend a day or so not so much 'fixing' those items but at least putting a little time into correcting the worst bits.

I think it might come from a book called Clean Code in which the author gives a rule that you should leave a source file cleaner than you found it.

Perfection is the enemy of completion. You might consider a prescription for anti-anxiety meds: if you're paralysed by fear it's probably already affecting other aspects of your life.