

Ask HN: How to prevent bugs in your code? - codereview

We're struggling with bugs. Of course they are a reality, but what are some ways to prevent and fix bugs quickly?
======
samikc
The short answer is: You can’t. But you can try.

Try doing the following to reduce bugs:

1.Write a lot of unit test cases covering all know scenarios that you have in
your spec or mind. This only assures that there are no bugs in your set of
test cases, however there could be bugs lying out side your test case set.

2.Before changing your code check if you have test cases written for the code.
If not do step 1.

3.Have good logging for your code in action. If a bug is found later it will
help you to root cause it.

4.If you are in object oriented programming try to replace if else codes with
polymorphism. Its difficult but if you can it will either reduce logical bugs
or help you find them quickly as they unfold.

5.Test for all if and else conditions. All if condition with complex logical
arguments (using AND / OR) must be checked for all conditions.

6.Learn from your mistakes in coding and try not to repeat them.

That said, its easier said than done. I would follow this thread how other
suggests and learn.

------
kellros
Well it's actually quite simple - the amount of bugs depends on the amount of
code - less code, less bugs.

To truly eliminate bugs, you either need to be able to see the future or have
learned from your mistakes and from others' mistakes. (The latter being more
common)

Depending on what you're doing, chances are if there isn't a clear separation
of concerns and you're not following good/best practices (ia. solid, grasp,
design patterns, ddd/tdd/bdd/*design) and - proper planning - there will be
bugs.

Another thing developers generally struggle with is calling something by its
name, ex. var a = 13 vs. var age = 13. That generally confuses even the
developer himself after he went to take a leak.

I also agree on all Samikcs points - in addition to that there is really a lot
of different ways to 'test code' ea, integration testing, unit testing,
behavioral testing, requirements testing, deployment testing etc. - even
software testers have to attend courses/study.

If you've read up to here, you will have realised there is no one answer.
Programming isn't a task to be taken light-heartedly. Plan. Develop. Test.
Verify. Repeat.

------
powatom
Finding bugs: I'm a big believer in Linus' law - which basically says that the
more people look at your code, the more likely you are to identify bugs.

In my experience, the single best way to identify bugs and other problems is
to have a good code review process. Any at all is better than none. Code
review can be frightening for the person whose code is being picked apart, but
it is important to remember that it shouldn't be a personal thing. Even the
best developers in the world write bugs - it's just the nature of the beast.

If you don't have a continuous integration process, think seriously about
implementing one. It can be a pain in the arse to set up continuous
integration after a project is already well under way, but do it anyway -
because it will most likely save you a ton of time further down the road.

------
RollAHardSix
Pass the code around to group-think.

Test-Cases!

Pray to Buddha to bring you a pony and a plastic rocket.

'Read' your code. Start at the top, draw your way (manually) all the way down
through each line, each decision structure, until you have reached the end.
Then go back up and do it all again but with a slightly different path. (Not
for large code segments; more just for smaller, components.)

------
LaaT
Well, start with collecting statistics and see if there's a recurring theme in
your bugs. You can't find a cure, if you don't know what the disease is.

------
hboon
1\. Think carefully before you code.

2\. Then you code.

3\. Read what you just coded.

4\. Peer review before/after you checked it in.

