Do you compile and run code very often or write large code pieces at once?

Question

When you code, do you write a few lines at a time, compile and run, write a little more, compile and run etc.? Or do you usually write large chunks at once without compiling? Has this work style changed over time for you?

Answer 1

I always write little, and compile often. This helps me isolate bugs very quickly. Of course in some projects compilation itself is expensive, I guess I'm fortunate that my projects haven't been like that so far.

Answer 2

Always keep your code in a working state. Write some code, compile it and test that it runs correctly. This is the habit that had kept me off the debugger for years, at least for new code I've written myself. It's one of the most important habits a programmer can acquire. When I see a new coder writing dozens of lines and then spending an hour compiling and debugging them, I immediately know how to help him become much more productive.

Better yet, write unit tests to make sure these correctness tests persist, because otherwise you're just throwing a lot of little tests away, and these may be useful in the future. This was an insight a few years ago, but then I discovered it's actually very popular. Your language of choice certainly has a few libraries / frameworks that make unit-testing easier - you should definitely learn about them.

Some people will take this farther and insist that you must write tests before the code. This is taking it too far, I feel, especially for a newbie. What's really important is that you have the tests. Which comes first is certainly less critical.

Answer 3

If I'm writing new code in a langauge I know well, I'll write a file of functions. The functions tend to be short (25-35 lines), then compile the file and iron out the mistakes.

If I'm writing in a language I don't know well, I definitely write in fragments.

Answer 4

When you code, do you write a few lines at a time, compile and run, write a little more, compile and run etc.?

Compiling is all well and good, but that just tells you whether your code is syntactically valid or not. And a good IDE will catch this for you anyway, especially when you're leveraging extensions like ReSharper. Unfortunately, a successful compile tells you almost nothing about whether your code is correct (absent any static design-by-contract features your particular language may have).

It's much more important to have good unit tests, and to run these whenever you make a nontrivial change. This is what gives you the hint that you haven't broken anything. Even better, write your tests first so that they'll fail until you finish implementing the new feature. (In practice I'd say that writing your tests first is very helpful but not strictly necessary.)

If your project has more than a few modules that work with each other, you'll also want to consider having a continuous integration process set up sooner rather than later. This is what will tell you whether your changes are not only correct, but that they also work well with the rest of your project.

Answer 5

I would argue that if you're working on a large project its a good idea to make sure your build system will allow you to compile a single file or group of files so you can compile often.

Answer 6

It depends, if the type of work is so familiar, then I will be writing large amount of code. Sometimes we'll be forced to write small peice of code if things are completely unknown and doing from scrath.

I still remember, in one of my project, I heard lot of scolding from my manager for running the code(he sux BTW). He said,

It's coding phase, you're not supposed to test your code this time, so stick writing code only. You will get time to test the code later.

But the type of work I was doing was to developer new visual components which should be accurate and meet the specifications of the customer and I was doing that kind of work for the first time. So it depends on your knoledge, experience, confidence, skills, your manager and other stakeholders above your head.

Answer 7

Thanks to the wonders of today's IDEs, I wouldn't normally expect to see any compilation errors unless you are coding "backwards". (e.g. within your class, you decide to type the name of another class that does not currently exist and then use the "red" compilation error to alt-enter and create that class). So I wouldn't explicitly need to press a "compile" button at all.

My cycle would be the TDD cycle of:

Write my test -> Write the simplest thing to satisfy my test -> check my code in -> refactor -> check my code in -> repeat

If I am "hooking in" my code with the rest of the code base, I will run the full build to make sure everything is working.

After hooking it in and I make a slight change to production code, I may then choose to run all the tests within the IDE to give me confidence that everything is okay. If something is terribly wrong, that's when my good friend "automated build" (e.g. cruise) gives me a whack on the back of the head.

Answer 8

I have always used the approach - "write a little, then compile and test". If I'm starting from scratch, I will create an empty program shell, compile and run it. Then start adding code.

This goes for any code I write - EVEN THE UNIT TESTS.

It only takes one time (in my experience) trying to debug 150 lines of "stuff", trying ot find the hidden bug to cure you of that illness. ;-)

It's also how I've been teaching programming since I started in 1990.

Cheers,

-R

Answer 9

Every time I write a piece of code I can test, I test it right away, so I compile and run every 5 to 20 minutes depending on how well I can break down the task that I'm doing.

That said, I don't have automated unit tests, so this strategy is the primary way I avoid bugs. Your mileage may vary.

Answer 10

Depends on the context and my mood, but overall I ensure my code always compiles and try to run as often as possible to reduce the amount of debugging needed at the end.

When debugging or refactoring, I have a very tight code-compile-run loop so I can quickly eliminate potential problems.

Other times I will code out everything ahead of time but then slowly step my way through execution. That is, I add forced conditions or early returns to verify specific behavior.

When implementing a big or complex feature, I keep the code-compile cycle going but don't run until I can verify something is working right (possibly via debug/stub code).

Answer 11

Unless it is a major refactoring change I suggest always keeping your code compiling. Your code should never be a couple of comments away from compiling.

Answer 12

The answer to your question is it depends. I think to do your question justice, a perspective greater than either or is important.

Real-time IDE Syntax Checking and Unit Testing

Nowadays, I often write large chunks of code without compiling because my IDE does syntax and compiler checking real-time as I code, thus eliminating the need to compile to check for syntactic mistakes. If anything, I find myself running unit tests against the code I'm writing more often than compiling, just to make sure my code is fulfilling its contract. However, since I have to recompile to use my unit tests, one could count that as a recompiling often.

Decoupling and Libraries

I try to put large "finished" sections of code into libraries (in my case jars), if I am working with thousands of source files. Particularly good candidates for this groups of files/packages that are not tightly coupled with other parts of the code base. I notice that as time goes on and the classes increase that it makes more and more sense to take this approach because it speeds up your "one-off" compilation time and reduces the chances of having problems with statically compiled variables getting out of sync.

Answer 13

I like do a lot of debug/trace logging (I seldom use the IDE's debugger) so I often run an incomplete piece of code to see that the log output is what I expected. I usually use unit tests (even if they are currently failing) to perform this function.

That said, I don't get bent out of shape if I'm working on a large change and it's not compiling yet or producing testable output (so long as I'm headed that direction.)

I definitely make sure all unit tests are passing before checking in code.

Answer 14

The worst experience ever writing large code at once was when i was a kid, and decided to make a killer program on a C64. I spent 8 hours straight of coding. I didn't even save (saving/loading was a bit clumsy with a tape, so i figured i'll save when i have a fully working version.) The first line of the program was "10 NEW". When i finally decided to run it, it took me a few seconds to realize why i saw that "READY" prompt so fast.

Anyway, it taught me to save a lot and also build/run a lot to prevent any such disasters from ever happening again.