Is there a better strategy than relying on the compiler to catch errors?
- by koan
I've been programming in C and C++ for some time, although I would say I'm far from being an expert. For some time, I've been using various strategies to develop my code such as unit tests, test driven design, code reviews and so on.
When I wrote my first programs in BASIC, I typed in long blocks before finding they would not run and they were a nightmare to debug. So I learned to write a small bit and then test it.
These days, I often find myself repeatedly writing a small bit of code then using the compiler to find all the mistakes. That's OK if it picks up a typo but when you start adjusting the parameters types etc just to make it compile you can screw up the design. It also seems that the compiler is creeping into the design process when it should only be used for checking syntax.
There's a danger here of over reliance on the compiler to make my programs better. Are there better strategies than this?
I vaguely remember some time ago an article on a company developing a type of C compiler where an extra header file also specified the prototypes. The idea was that inconsistencies in the API definition would be easier to catch if you had to define it twice in different ways.
