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.

Especially when writing new code from scratch in C, I find myself writing code for hours, even days without running the compiler for anything but an occasional syntax check.

I tend to write bigger chunks of code carefully and test thoroughly only when I'm convinced that the code does what it's supposed to do by analysing the flow in my head. Don't get me wrong - I wouldn't write 1000 lines without testing at all (that would be gambling), but I would write a whole subroutine and test it (and fix it if necessary) after I think I'm finished.

On the other side, I've seen mostly newbies that run & test their code after every line they enter in the editor and think that debuggers can be a substitute for carefulness and sanity. I consider this to be a lot of distraction once you've learned the language syntax.

What do you think is the right balance between the two approaches? Of course the first one requires more experience, but does it affect productivity positively or negatively? Does the second one help you spot errors at a finer level?

share|improve this question

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, GlenH7, MichaelT, World Engineer Mar 26 at 15:29

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
It takes you hours or days to write a whole subroutine? –  user1249 Dec 23 '10 at 1:19
1  
@Thorbjorn The subroutine is about 999 lines long, and it's obfuscated: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r‌​+z))); goto xkcd) And that's only one line. –  muntoo Dec 23 '10 at 7:00
1  
compilers can sometimes take a long time to compile a program whoch is why it's not good practice to compile all the time. after every function is good practice. i recompile after adding new functionality or some difficult piece of code. I only use it as a syntax checker. there is no substitute for checking over your code carefully and avoiding hidden errors and haphazard behaviour. –  Ross Dec 23 '10 at 7:56
add comment

12 Answers

up vote 4 down vote accepted

It REALLY depends on the aspect of the project you're working on.

  • When I do anything with OpenGL (which works like a state machine), I constantly compile and run to make sure that I didn't accidentally screw up anything. Setting one value without remembering to reset it at the end of a function can easily make the application render only a black screen.

  • For larger scale "under the hood" development, I try to get as many tests as possible beforehand. Since the tests can more easily tell me what broke, I can go a while without having to wait for the typically long compile.

  • For UX design, I use some sort of visual designer, which always looks the way it will run (or close to it). It is essentially always compiling the design code.

share|improve this answer
add comment

Personally, I must work in small chunks because I am not smart enough to keep hours worth of coding in my biological L1 cache. Because of my limited capabilities, I write small, cohesive methods and design objects to have very loose coupling. More powerful tools and languages make it easier to code longer without building, but there is still a limit for me.

My preference is to write a small piece, verify that it works as I expect. Then, in theory, I am free to forget about the details of that piece and treat it as a black box as much possible.

share|improve this answer
12  
Upvote for "...not smart enough.." I have felt that way for quite some time. –  leed25d Dec 22 '10 at 18:21
4  
What about your L2 cache? –  muntoo Dec 23 '10 at 7:07
8  
+1 for use of the phrase "my biological L1 cache" –  Nick Moore Dec 23 '10 at 10:49
    
I was going to upvote this, but the score is at 42... –  Wayne Werner May 9 '11 at 2:03
    
The newer models have much bigger L1 caches. When did you buy yours? You may want to go for a hardware update. –  Peter Ajtai Jan 17 '12 at 23:35
show 1 more comment

I like to write my test before I write my implementation code. I like this for three reasons:

  1. Writing my test code before hand helps me think through how my code should be used. It helps me think of edge cases that I didn't think of when I was originally designing my program.
  2. I know I am finished writing implementation code when all of my test cases pass.
  3. Getting into the habit of writing tests before code also has the added effect of being able to prove that your code has not added any new bugs (assuming you've written good test cases).
share|improve this answer
2  
"I know I am finished writing implementation code when all of my test cases pass." - How do you determine if you wrote all the necessary test cases? –  dss539 Dec 22 '10 at 18:32
1  
That's a great question. In my opinion, you can never be completely certain that your code functions correctly unless you have a formal proof stating so. I view unit tests as evidence that your code tends to do what you mean it to do. But, as the features you add grow, the number of test cases you'll write will probably grow too. If in doubt, ask someone else to look at your test cases and ask them for cases that you haven't thought of. –  David Dec 22 '10 at 18:37
3  
@David - how do you formally prove that your formal proof has no errors? How do you formally prove that the requirements as perceived by you match the in-reality requirements. You can formally prove that one description matches another, but it is perfectly possible that both descriptions are incorrect in the same way - especially if both descriptions were written by the same person. Writing things in math notation doesn't make people infallible. Huge numbers of mathematical "proofs" have proven (after long periods of very detailed checking) to be wrong. –  Steve314 Dec 22 '10 at 19:46
1  
@Steve314: AFAIK, when formally proving the correctness of an algorithm, you specify exactly and concisely the what the expected correctness is. You bring up a good point though, that the definition of "correctness" may not actually be correct. –  David Dec 22 '10 at 19:52
1  
@dss539, that comes from the use cases that the program is intented to implement. –  user1249 Dec 23 '10 at 1:20
show 3 more comments

I find myself writing code for hours, even days without running the compiler for anything but an occasional syntax check.

Hours to days - that's a clear sign that you miss the ability to break down your code into smaller chunks which can be verified and tested on their own. You should definitely work on that.

I tend to write bigger chunks of code carefully and test thoroughly only when I'm convinced that the code does what it's supposed to do by analysing the flow in my head.

Instead of writing bigger - and thus complicated - chunks of code which needs hours to be analysed in your head, you should try to create smaller, not so big building blocks. This is called building abstractions - and that's the gist of good programming, definitely not a sign of beeing a newbie.

Excellent programming is like excellent Billard playing - a good player does not play hard strokes. Instead, he plays in a way where after each stroke the balls stop in a position where the next stroke is easy again. And a programmer is not good because he can write complicated code - he is good because he can avoid writing complicated code.

share|improve this answer
add comment

I compile & test if one of the following conditions is satisfied:

  • Last compile was 15 minutes ago
  • Last compile was 25 lines ago
  • New function/subroutine has been implemented
  • Major change
  • New feature (or a bug disguised as a feature)
  • Bug fix (removed a "feature")
  • I'm Bored
share|improve this answer
add comment

How often I run and test code depends on what language I'm working with at the time. If I'm coding a stored procedure, I'll usually wait until everything's there.

On the other hand, if I'm coding in Lisp, I'll try each function after I type it in.

If I'm coding in Haskell, I'll typically do a compile after each function to catch any type errors, and run the code after everything's done.

share|improve this answer
add comment

I write just enough code to get test to green. That means I run test every few minutes. That's my C++ style. However in Ruby I use autotest, so every time I hit save I get tests feedback via nice popup. I don't even stop writing code, it just happens in background.

share|improve this answer
add comment

Thrice an hour, whether it needs it or not.

We do test-first programming and commit only working code to the VCS. The smolderbot goes and checks out the repo every 20 minutes and runs the test suite. Any failures are immediately mailed to the entire programming team for immediate fixing.

share|improve this answer
add comment

For me it's not about how much I write. I can write thousands of lines of simple code without having to test it. But when I'm writing more difficult code I tend to test each function individually after having written a cohesive set of them.

Sometimes though, seeing your code running is a huge motivational boost, when you haven't run anything in a while it's good to see it working.

share|improve this answer
add comment

For me ;-
Short timeline (not much time to think)- write code, compile, test. debug
Sufficient time - while(done) {write small code, compile}, test, debug

share|improve this answer
    
I find that the former takes longer than the latter: you have more to debug that if you have a very small test/write loop. –  Frank Shearar Dec 22 '10 at 20:51
    
May be. But short timeline means ass is on fire, and the manager needs report which says some task is 100% done. –  Manoj R Dec 23 '10 at 5:16
add comment

I test for each coding concept. Sometimes this is a function or class and sometimes it is nothing more than an if statement. Once the concept works, go on to the next one.

share|improve this answer
add comment

I try and write tests before the code. I run my tests at least twice before a commit. It then runs again with the Continous Integration server.

share|improve this answer
add comment

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