16

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?

Improve this question
3
  • 3
    It takes you hours or days to write a whole subroutine? Commented Dec 23, 2010 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. Commented Dec 23, 2010 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. Commented Dec 23, 2010 at 7:56

12 Answers 12

Reset to default
5

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.

Improve this answer
63

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.

Improve this answer
5
  • 12
    Upvote for "...not smart enough.." I have felt that way for quite some time. Commented Dec 22, 2010 at 18:21
  • 4
    What about your L2 cache? Commented Dec 23, 2010 at 7:07
  • I was going to upvote this, but the score is at 42... Commented May 9, 2011 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. Commented Jan 17, 2012 at 23:35
  • Well its not the age of the model so much as the fact that it was the "budget" line. :( Commented Jan 20, 2012 at 15:10
17

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).
Improve this answer
8
  • 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? Commented Dec 22, 2010 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. Commented Dec 22, 2010 at 18:37
  • 4
    @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. Commented Dec 22, 2010 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. Commented Dec 22, 2010 at 19:52
  • 1
    @dss539, that comes from the use cases that the program is intented to implement. Commented Dec 23, 2010 at 1:20
4

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.

Improve this answer
3

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
Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
0

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

Improve this answer
2
  • 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. Commented Dec 22, 2010 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. Commented Dec 23, 2010 at 5:16
0

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.

Improve this answer
0

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.

Improve this answer