Hey all,
I'm wondering if anyone else has this "fear" of writing bad code. The problem is once I start writing code I stop because I'm afraid its bad code. Is it bad to write bad code? Won't writing bad code stay with you or something and how can I practice to write better code?
Thanks in advance!
Cenox
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
I have to agree with Ravyne, with only one modification/addition to make. Even when you know all the good/bad practices, making your code work without constantly backtracking to correct things is a notable goal. While I don't necessary like the concept of agile programming in general, I do pick bits and pieces from that and other areas as I go. In this area, I do tend to agree with agile, just write the damned thing and make it work, sure it can be horrible stuff at the end but if it is working the primary goal is out of the way. But, additionally, instead of stopping and refactoring at each problem, you now have understanding of all the problems and can take the overall result as a whole in account if/when you desire to refactor it.
Of course, as RedBaron just stated, working code is a hell of a lot more impressive than half completed "pretty" code. 
The tutorial code I've been using in my articles ranges from stuff I'm fairly happy with to stuff I really didn't write, it was my evil twin... really it was ...... I hopefully commented the really horrible bits and mentioned why they are not refactored at the moment, but if not, oops. Overall the code functions for what it is being used for, that's really all that matters.
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.
It's just an idea. The primary response to bad/dirty code is run and hide or immediately fix it. Get over it, EVERYONE writes dirty/bad code sometimes, just keep moving forward and making notes as you go. Don't get defensive about bad code, sure it is embarrassing but fixing every little detail doesn't lead to complete shippable products. Learning to write better code next time and of course identifying the bad stuff, you learn with practice.
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.
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.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.
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.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?
Thanks again for the repsonses
Cenox
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.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.
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.
