Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
Rely on the programmer to catch errors... through analysis, understanding, testing, and compilation. –  dietbuddha Mar 19 '12 at 22:43
add comment

5 Answers 5

Don't adjust things to make it compile. Adjust things to be correct. If it was "designed" so that the parameter types didn't match, then the designer doesn't have any idea what they're doing.

If you don't want to rely on the compiler, then improve your knowledge of the language. Study the structure of definitions and declarations, and check what you write for errors before compiling. And use code reviews.

That extra prototypes idea sounds bad. If you design it wrong once, what's to stop the second design from being designed wrong? And by using different formats/paradigms/etc for the same thing, you're likely to confuse people. I would make sure everyone understands the primary format so that you can focus on getting the design right the first time, rather than doubling the design work to catch errors. Like everything else, designs should be refactored, but I don't think doing it twice to begin with makes much sense.

share|improve this answer
    
I think the designer (me) didn't remember the parameter to the other function correctly, probably because I'm thinking of a previous version of the design. –  koan Dec 29 '10 at 21:26
    
The second header file was not written in standard C and I think it was of the form of higher level prototypes. The idea was that if your two different definitions defined the same thing then your design is more likely to be correct. It wasn't two standard C header files but with different "typing". –  koan Dec 29 '10 at 21:29
    
But that was at the implementation stage, right? Either way just change it to follow the design or change the design to be correct ... don't just make the compiler happy ;). I'll update my answer to reflect your explanation of the prototypes. –  Matthew Read Dec 29 '10 at 21:29
    
I get your point and I think it's a good answer but at what stage do you say "Whoa, I need to stop all implementation and go back to getting the design right", because 'just changing the design' can be done quickly, too quickly, thoroughly or too thoroughly... –  koan Dec 31 '10 at 10:15
    
That's a really hard question to answer. I think it's more of an experience-based feeling than anything else, except when you encounter the rare "whoa, we completely misunderstood this problem, need to re-do the design". –  Matthew Read Jan 1 '11 at 3:54
add comment

Honestly, I believe your goal should ALWAYS be to write a program that compiles on the first time. I realize that this is hard and probably will not happen frequently, but it still should be your goal. Think of the software as a piece hardware. Make yourself believe that it unrealistically expensive to recompile your code (like re-manufacturing a a board). A complier is not a debugger and it shouldn't be treated as such.

share|improve this answer
    
+1 for "the compiler is not a debugger" –  Joris Meys Dec 29 '10 at 21:06
    
Interesting. I always felt much more comfortable if I found an error because inevitably they exist in my code, it's just that I haven't found them yet. My question is not so much about debugging though; I'm looking for strategies for designing or writing code that are more effective in producing good code. For example, if your compiler gives more than X non-trivial error messages you should stop and rethink the design; or something. –  koan Dec 29 '10 at 21:35
    
I think your best bet in terms of learning how to write good code is to read a book about. I recommend Code Complete. It is the best the book that I have personally read about software in general. –  Pemdas Dec 30 '10 at 5:04
    
I feel you are trying to nullify the problem by not having it in the first place. That's no bad thing, but ultimately there are going to be problems that crop up during compilation, no one is perfect after all. –  koan Dec 31 '10 at 10:17
1  
While a compiler is not a debugger - one of my preferred ways of doing certain refactorings is to make it such that old code will not compile (by renaming perhaps). Makes it easy to find things that were missed. –  sdg Jan 25 '11 at 17:58
show 2 more comments

The compiler can't find all the mistakes so there's no point in pretending it can. All it can find are the syntax errors and typos. It's good enough at that that I let it do that part of the job (although these days the environment catches 99% of those itself before you ever hit compile) but I perfectly well know that's not all the errors.

The only time I rely on that sort of information to tell me what to write is when I get things like it telling me it can't automatically convert a double into a float--if where you are sending the data expects floats (and since what I'm currently doing is playing with the XNA library that does exactly this) and the source returns doubles (as is the case for the C# math library) then you simply have to convert.

share|improve this answer
add comment

The compiler is a tool. As with all tools, they can be abused.

When you're first starting out with a language there's nothing wrong with using the compiler blindly to test your program. That's inherently how learning works, guess and check. However, that does not mean you should continue to code like that.

It is in your best interest to understand the language well enough so that you could compile your program in your head. Then you will spend less time waiting for the compiler to finish.

I say it's probably best that the program is always within a few lines/blocks of code of being compilable.

share|improve this answer
add comment

Most modern IDE's catch a lot of compiler issues and I guess I have become quite reliant on this too.

Maybe move back to text files and command line compilers?

share|improve this answer
    
I don't use an IDE! Maybe I should start? I've always thought I should but never found one that I was happy with. –  koan Jan 31 '11 at 14:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.