Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Stuck in late development


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#21 jefferytitan   Crossbones+   -  Reputation: 2428

Like
0Likes
Like

Posted 12 September 2012 - 04:06 PM

What most of the people have said: every programmer makes mistakes (even Carmack), good programmers make fewer mistakes and fix them sooner. If you've been avoiding bug fixing it makes your job harder. If an area of code has many bugs they may interact in weird and wonderful manners than make diagnosis difficult. But still possible. Get to a better mindset, then get to it. You'd regret abandoning your hard work.

Sponsor:

#22 Codarki   Members   -  Reputation: 462

Like
0Likes
Like

Posted 13 September 2012 - 08:37 AM

To fix a bug ridden codebase:
- Set compiler warnings to the max, set compiler to treat every warning as error, and fix (or silence) the errors.
- Add a lot of asserts, specially for function preconditions.
- Make sure you read return values everywhere, and check them for errors.
- Rename poorly named classes and functions to be more clear.
- Use const-correctness.
- Fail fast

If using visual studio:
- Set debugger to break whenever exception is thrown.

Is you codebase riddled with null-checks? Optional codepaths if/when something fails?

http://www.martinfow...re/failFast.pdf

Some people recommend making your software robust by working around problems automatically. This results in the software "failing slowly." The program continues working right after an error but fails in strange ways later on. A system that fails fast does exactly the opposite: when a problem occurs, it fails immediately and visibly. Failing fast is a nonintuitive technique: "failing immediately and visibly" sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS