How to make code writing more accurate?

Question

I am trying to practice writing code for a long period of time before compiling and write unit test (if possible) for what I wrote (the language is C++). Of course, I got the IDE support (Emacs or Eclipse for on the fly error detection and code completion) with minimal or no error. I practice this ability because the pattern "trial and error" in which a bit of code is written and then build/run to check the correctness is not productive as I feel.

However, isn't what I am doing counter the purpose of testing? Maybe, the point of my practice is not to assure 100% logic correctness, but rather, 100% or close to 100% syntax correctness, in order to vastly improve productivity. I will try to practice with the small piece of code first, and then improve gradually as time passes.

What's your opinion on code writing and productivity in general? Do you practice like I do or do you have much better method? (Aside from being in the "flow", or extremely concentration). I concern this matter because I heard that some people are an actual human compiler, and it seems like they can directly translate the logic to code as their natural language.

Edit: I was a bit wrong when I mentioned not to improve logical correctness. Yes, logical correctness counts as well. What I want is to practice programming to the point where I can keep writing code for a long period of time with minimal mistakes (such as I can write 1000 lines of code,a and only a few trivial errors occur).In case of C++ or any language, using external libraries require you to understand many dependencies of the libraries to use it correctly in your code. For example, if you use Spring framework in Java, you have to make sure the xml, the server etc... are set up correctly. I consider this is also a form of syntax, and one way to achieve "syntax correctness" is to practice it frequently to the point when you can minimize the most mistakes written by hands. This is similar to when we first start learning programming, sometimes/often we miss the semicolon. Then we learn the mistake and improve it.

Answer 1

Fixing syntax errors represents only a tiny fraction of the total amount of time that we programmers spend while doing our job. I mean, it is so tiny that it gets lost in the noise. The compiler points them out to you, you fix them, and you both move on.

Even typing is not the bottleneck, so a slow typer is generally not at any great disadvantage over a fast typer.

Fixing logical errors gets somewhat closer to representing a significant portion of our work effort, but still, that is not the biggest time waster.

Design refactoring (When we realize that the way we were trying to do something is not going to work, and we have to rewrite the whole thing from the beginning) is probably the single thing that we waste most of our time doing.

So, what do we learn from that? Our job is mostly about managing the complexity of the problems we are trying to solve. And that's a whiteboard and marker problem. A nice development environment and tools help, but precisely what we do with them does not really count that much, because the greatest bottleneck by far is the design.

Answer 2

A good testing has nothing to do with correct syntax. The compiler does this for you. A good testing is one, which covers a high percentage of your code and a wide range of special cases, not one that happens often. Use unit tests wherever possible. These allow you to repeat the tests, after you have made changes to your code. This ensures that the changes and additions are not breaking the existing logic.

Answer 3

Although there's nothing wrong with practicing to write correct code, I would strongly advise you from attempting and practicing to write code without testing or compiling for long lengths of time. Instead, I would suggest complete opposite to that, compile and test your code as often as you can.

You can significantly minimize debugging time if you write one small segment of code and when you compile/run something doesn't work and needs to be fixed. If you wrote 5 classes and 30 functions and then run everything, you'll have a hell of a time finding all the logic errors even after you get past 80 compilation errors.

Also, depending on which IDE you are using, you might be able to write faster code if what was written previously is compilable. For example VS2010 IDE will continuously compile your code in the background to rebuild its IntelliSense database, so if you made a syntax error, you might lose function/variable name lookup.

As far as training yourself to make less mistakes, I think it'll come eventually regardless of how frequently (or infrequently) you build/execute your code. As long as you are paying attention to what kind of things you miss and actively trying to reduce the error rate, you should be fine. The other thing I would also practice is maintaining a consistent coding style. Don't simply let IDE format everything for you but make sure every time you insert a space or new line that you mean it. I think being careful with every keystroke and paying attention to what you are typing, not only produces cleaner, more readable code but also helps you not make the simple syntax mistakes as often.

Answer 4

I've found if that if I know the resources/tools/classes I'm using, I can write whole large programs without trying anything. (These new-fangled IDE's that point out your mistakes instantly do help a lot.) And the program usually works as intended, too. (Okay, after a few NullPointerExceptions are fixed.) Whether my intent was any good is quite a different question, but I needed to run the whole program to find that out anyway.

But when I don't know for sure how the tools work, or how it's going to look to the user, I'm always testing things. When I'd never used a socket before, I wanted to see data flow before I wrote 1000's of lines of code on the assumption it would. And I have never gotten comfortable with graphics. For me graphics code is endless short cycles of change a bit of the code, try it, change the code, try it,....

I don't think I'm trying to write lots of code without testing it. I'm just trying to spec out the program. I could do it in English, or pseudo-code, or in diagrams. I prefer, these days, Java or C#. That way, when I've got my program thoroughly specced, it's ready to be shipped. Er, I mean I can test and check the design.

I've always felt a bit like Wile E. Coyote. I code flat out, but I've become extremely sensitive to that feeling you get when you're standing on thin air. The trick is to get back to solid ground--test the code--before gravity kicks in. I'm better at this than Wile E. was.

Interestingly, most of large chunks of bad code I've had to throw away I tossed long before I ever tested them. They resulted from flaws in my design that became obvious when I tried to code the details.

In your case, just do what you're comfortable with. If your tests aren't telling you anything interesting, start skipping them. If you finish a big program that depends on the OS doing five key things for you, and it turns out the OS can't do any of them--well, test a bit more in the future. Trying to push yourself in either direction is a bad idea.

I think I'm disagreeing somewhat with DXM here, but if he hadn't written it already I'd finish with his last paragraph ("As far as training yourself to make less mistakes...").

Answer 5

Like all things in life, you should be trying to find a balance that works for you. You want to maximize your productive time by trimming away wasteful practices, which is good Lean thinking, however this needs to be done without incurring a wasteful cost elsewhere, and it's here I see the greatest risk when you state your desire to code for long periods of time without compiling.

Think about what you are doing when you write software. You spend time thinking, and typing, and correcting, and testing, debugging, and so on. Chances are that you probably spend less time simply typing in code that will work first time, unless you are a serious genius or perhaps a little OCD as you type.

So how do you test your code? Do you write tests first, or do you do all of your testing at the end? Both options will have a serious impact on the time it takes to successfully implement your code. Many of us who have been practicing Agile for years now have found that writing tests before writing code results in an overall efficiency increase. This is because the testing is done, out of the way, and you only write enough code to make the tests pass. It's lean, and while the up front development time is greater, the debug and test time is usually completed in a shorter time.

Yet regardless of whether you test first or test last, if there is one thing that I have learned the hard way over the years, its that your greatest coding failures usually occur after your largest coding changes. Think about this for a moment. You are writing code, and you're in the zone so you just keep writing it. Suddenly you realize that something else needs to be changed ever so slightly in order to accommodate your code. You look at it carefully, make your changes, and continue coding. When you compile your code you suddenly find an error or two. After fixing the error, the code compiles for the second time, and when you execute your code, it works almost as you wanted it two, but there is a bug. Fix the bug, and recompile, then there is another bug... and so on. I'm describing this as an issue isolated to a single developer, but what happens when you are working on the same source files, and you need to deal with branches, merges etc...?

What I am trying to say, is that getting code compiling is the smallest part of a much broader exercise. Time spent up front refining your tests and executing them often against code is very efficient, because it saves you valuable time later on, particularly when your job involves working with other software developers. The real benefit however comes when working with a good unit testing framework, because you will be able to get instant feedback so that not only will you know if your code compiles, but you will also know instantly if your code actually works. This in itself is a huge time saver, because it can keep you from obsessing over the state of your code, freeing your attention up for other things.

Answer 6

Step 1: Try to draw the problem on whiteboard or paper (boxes, arrows, information-flows)

Step 2: Isolate logic and express it in pseudo-code (if input > 10 then do this, else do that)

Step 3: Write a unit-tests based on result of step 2

Step 4: Write code that passes the unit-tests in step 3

It's not always as straight-forward and I'm certainly no saint when it comes to following the tenets of TDD, but that is how I want it to look.