I’ts been a while since I coded… and I remember the types of mistakes I did, I do them again.
I like this CodinGame, because you can actually see some your code in action. Even a bug can resolve in a drunken Thor trying to get to light lol Yeah, I made him run a zigzag line in Power of Thor, just by writing $MyVarForX instead of $MyVarForY and I couldn’t find it.
Hope my eye sharpens for the bugs I write, so I can spot them easier. For now I would like to know how you avoid your bugs and how you spot them.
Even after years and years of coding, you make this kind of typo. You write data instead of date, or you copy/paste a for loop without rewriting the variable name … That’s why you need to test your code.
In the real working world, you (in theory) have multiple ways to spot this errors:
Your code is supposed to be tested and you should spot this errors because the tests will crash
You can do pair programming. Your pair will see this errors. “you are coding sh*t right here”
Others devs can spot it during the code review
This errors are humans. You can’t say “i will never make a typo in my code”. It’s impossible. You just have to establish methods to spots them.
That’s true: one never stop doing errors. However, in my experience, beginners have an uncanny talent to put themselves in the hardest situations, creating fascinating and convoluted bugs involving various settings, tools and constructions, none of them meant to be used this way. It sometime creative, almost explosive all the time. At least, when you are experienced enough, even if you can still blow you leg by accident from time to time, you know at least that wielding a crossguard lightsaber is just calling for injuries.
Of course errors are normal. Thanks for reminding me . We shouldn’t have left the
Sounds a like coding is best done in teamwork, than learning coding should be in teamwork, too. A further power of CodinGame
I don’t have the luxury of working in a programming team. I’m the one programmer in the melting department for a steel mill. We don’t make software, we make steel, so no one cares how well the data handling software is written as long as it works. So no code reviews and no team programming. From everything I read on the subject I’ve come to realize a job like mine is pretty unusual, but it’s what I have to work with so I make do. With that in mind, there are ways to help yourself spot bugs quickly and minimize the number you create, even as a solo guy. It’s a whole lot of little things that mostly fall under the same heading:
Coding standards. No one is going to enforce them on you here but when you consistently follow a logical standard, you’ll train your eyes to spot things out of place. Simple things (like always putting the body of an IF statement in braces even when it’s not strictly required, which prevents a very common mistake) make the code look a certain way and pull your eye to parts of the code that don’t look right. There are lots of examples of usable coding standards on the net for reference. Most of them are written with bug prevention and detection as the primary goal.
