Overcome clumsiness in writing code

Question

I believe this is a little related with this question: How to be a zero-bug programmer?. But I believe this is more regarding clumsiness in programming because I know it is impossible to become a zero bug programmer.

Often, I write a very buggy code caused by my own clumsiness. For example in writing a currency rate conversion function, a trivial function. I can code the function that running well given the correct value. But sometime I just forgot to validate some unexpected-but-reasonable values.

So are there any ways for clumsy programmer like me to write and test the code more thoroughly?

Additional I see a lot of people suggesting to write unit test or using TDD approach. But writing unit-test not always goes well because of clumsiness isn't it? I don't because I once tried to write unit-test, but still often bumps with bugs.

Answer 1

Try a different development approach: Test-Driven Development (TDD).

a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards...

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques...

Write test cases and use unit tests to prevent bugs from materializing.

Answer 2

Spend a little time as a tester - it will teach you to get into the "edge-case" mentality

Then put all your edge cases into unit tests for a TDD approach..

In addition to TDD, I think reading about Defensive Programming would be helpful too. Learning to assert your preconditions and postconditions in every method is a good practice, and be strict! :)

Answer 3

Think more about the requirements. Few people are really clumsy or unable to think of bugs; most just don't take the time to think about the appropriate aspects. If you take a little time and just think about the requirements of a function, you'll discover most of the necessary aspects.

Test-driven development is a hip and well-documented approach to get you focused on thinking about low-level requirements first.

Answer 4

In addition to TDD, I'd advise going back to the code a day or two after you've written it, and take a look at what your tests check for and what the function itself checks for. When coding, you may have a very specific idea of how the function will be called, which may become vaguer if you take some time. In addition to that, this is a great chance to take a look at how well-documented the function is, and add comments if you don't understand why it works.

You could also try coding with a Design by Contract framework, which can help catch some errors -- in your example, perhaps checking that the sign of the result is equal to the sign of the input, and that the result (if it's a float) is not NaN or infinity.

Answer 5

Learn other languages, preferably of different paradigms.

For instance if you've been using an imperative/OOP language like Java/C#/C++, try a functional language like Scala/Haskell/F#. (I suggest Haskell for your purpose since it's the most faithful to the paradigm.)

The advantage of learning a new language or new paradigm is that you will start seeing conceptual patterns that these other languages would have defined rigorously, and then when you go back to working in your language of choice, you can apply these patterns to your code and thus avoid bugs that used to be common otherwise.

TDD isn't the same thing as unit testing. In fact, many TDD practitioners will insist that TDD should not be used to catch bugs or regressions -- and that if you're writing TDD tests to catch bugs, you're losing the design benefits of TDD.

If you want to do testing to improve code quality, do unit testing and integration tests -- not TDD. Sure with TDD you'll develop a habit of spotting bugs up front, but that aspect of TDD really isn't much different from normal unit tests.

Answer 6

Testing is important but the testing itself will require a patience and an attention to details and so it does not go well with clumsiness, to start with. I'd rather suggest using languages with stricter type systems (in addition to the testing, not instead of it).

Stupid coding mistakes are very rare even for languages like Haskell - if it compiles at all, it is likely to run as expected. And such an errors are nearly impossible for the languages with stricter type systems, like Agda or Coq.

Answer 7

Stop and read your code very carefully before you even compile it. Think like the compiler- find any syntax errors (once you've gotten good, the compiler should never find a syntax error). Also work through the code in your head very thoroughly, play computer. View it as if you only have one chance to hit compile, and everything better work (in other words, be very careful about what you do, don't mash the build command and then fix what pops out). This is a simple technique that is surprisingly effective.

Answer 8

There are very few people who can write the error-free code just from scratch. I personally feel always uneasy if rather long chunk of my code compiles and runs immediately and my intuition fails only seldom.

As long as you accept the these that you can not write the error-free code directly it is easier to find a trade-off between the efforts you invest into your code and the (potential) frequency of bugs in it.

One very good approach to minimizing the bugs in your code is the already mentioned Test-driven development. I use it often when I speak in public by adapting it in the following way.

Every independent piece of code is written and re-written in several iterations consisting of the following:

1. Design the main idea of what you code should do.
2. Write down the schematic representation of your algorithm.
3. Re-write the schematic representation so that it is syntactically correct.
4. Write some most important unit tests for your code (smoke test, for example).
5. Implement the algorithm to satisfy your existing test(s).
6. Refactor your code to improve it.
7. Repeat from 1-4 (depending upon the code maturity) for every iteration and every new feature.

Here are some examples.

(1) I start with something like

I want to calculate pi, so I will simulate a target being a circle with diameter d and use random numbers to cast arrows to it. I will then use the proportion of circle area to the total target size to calculate pi.

(2) Then I move to

Request size of the target.
Request number of arrows. Cast arrows randomly to the target.
Calculate the arrows that met the target.
Calculate the pi value.

(3) I re-write it in C# (just an example):

var Radius = RequestFromUser<double>("Radius of Target");
var NumberOfShots = RequestFromUser<long>("Number of shots");
long GoodShots = 0; long TotalShots = NumberOfShots;
while (--NumberofShots > 0)
{
  if (ShootTarget(Radius)) GoodShots++;
}
Output(CalculatePi(GoodShots, TotalShots));

(4) I create all method stubs in IDE (automatically). This allows me to write my unit tests in semi-automated way (get some templates automatically created for them)
(5) I design the smoke test:

var computed = ComputerPi(Radius: 10.0, NumberOfShots: 10000);
Assert.IsTrue(computed > 3.0 && computed < 3.5);

(6) I quickly (meaning without polishing the code) implement all stubs to start testing.
(7) As long as my tests shows green I re-factor my implementation trying to make it "nicer".
(8) I repeat from (5) if my implementation is not complete, or from an earlier step if I want to extend it.

This helps me to keep my code rather clean, and the slowly emerging unit tests serve as regression tests if I do too dramatic changes to my code.

Answer 9

Here's some good practises:

1. Step outside of the system
2. Enumerate all alternatives
3. Find the border of the system
4. Consider whole state space
5. Accuracy in deciding types - only allow exactly what was required
6. Consider path from input to output -- don't break the path.

Answer 10

The real answer is very simple and boring and doesn't involve tons of lists and instructions.

Code every day for 10 years and you will be great at it. That's it. You will end up figuring everything out along the way and refactor and refine yourself. Its the nature of the human brain.

Bruce Lee ended up figuring out that there is no one style of fighting, you have to adapt to your opponent.

In programming, there is no one style, you adapt to your problem. But you have to have done it for a long time to be a master at it.

That's it.