Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to improve the speed of my coding and I was wondering what tips the pros have. Currently I tend to code about 5-10 lines of code then test and repeat. Is that typical? Or is it better to code larger blocks of code then test. I am always worried of coding a lot than realizing all the code I wrote was wrong and would have to retype.

share|improve this question

migrated from Mar 22 '11 at 17:37

This question came from our site for professional and enthusiast programmers.

This seems like a better question for Programmers Stack Exchange – Robert Williams Mar 22 '11 at 17:36

I am one of those who write tests before the code. And by experience every test is about 5-10 lines (depending on the complexity), and every time I edit my code (5 - 15 lines), I test it. Sure it may take more lines and time for some parts, it really depends on what you're coding, UI, logical stuff, etc.

I'm not saying I have the absolute way of coding, but I think writing a working code first, might be slower on the moment, but after a while, you'll have saved much time of debugging.

That's my opinion though, good luck.

edit: Plus if it's I think your code should be very modular, well split, and easy to test.

share|improve this answer
Yea, I write test first then the code needed to pass the test. – Andy Wiesendanger Mar 22 '11 at 18:11
Good point. I tend to code like that to. But my managers want to see a lot of code written fast AND perform adequately. I am trying to find that good balance that can satisfy as many people as possible. – Robert Mar 22 '11 at 18:32
any test before code tutorials? – Spooks Mar 22 '11 at 21:37

I tend to write in blocks of code where each block does "something" and I test that "something". For instance I might pull data from a database in a function and once that's written I test it. The code might be 5 lines or 50 lines depending on the complexity. Once I have that "something that does something" I test it. Then I'll switch to ASPX and create some HTML with controls with's a hundred lines long that I test after its written. Then I bind those two together with a couple of lines of code and test that. I try to isolate my code into individual blocks that have given input and expected output ranges.

The biggest thing to learn is that errors are normal and are often easy to handle, especially if you do it early on. If you're passing values over the querystring, parse them out as soon as possible and sanity check them right away and stuff them into strongly typed values. Then your code later on will know that ArticleId is a valid integer.

share|improve this answer
I write in a similar fashion. Once a functional code has been written I test that. It could be anything from a database call to changing the text on a label. – Chuck Conway Mar 22 '11 at 18:12

I usually code until I am finished the block I am working on, then test. I don't think there is any real standard as to how many lines of code you should type before testing.

Most of the time this is a few lines like you said, although occasionally it can be a lot more. And sometimes (especially when coding the UI) it is nothing more than changing a single number or word.

share|improve this answer

To speed up my coding, I've learned the tools better. I spend hours in Visual Studio, it's silly to not know the how to leverage the tool, such as knowing the shortcuts.

Mirco-code generation/templating helps out immensely. Plain Visual Studio has code snippets. Tools such as Resharper or Code Rush have more advanced micro code generation.

I recommend The Productive Programmer. It's a little dated, but still chocked full of useful tips.

enter image description here

The Productive Programmer

share|improve this answer
I'd probably add Code Complete to that book recommendation as well. – Brandon Mar 22 '11 at 20:19

Honestly, banging out reams of code really isn't what I look for as a measure of productivity in other programmers. I'm more interested in:

  • Do you write clean and clear code? Commented if necessary (shouldn't need them usually)?
  • Do your tasks come back from QA with bugs (or worse, from the production environment)?
  • Do you communicate well with others so that if you get stuck, you can (and will) ask for help? Or can help out someone else if they need it?

I almost never find myself writing code exclusively for an extended period of time. Usually you have to step back to think about what you're doing and what other widgets you're going to affect. I'm not sure that coding speed really matters that much at the end of the day (provided you're being productive).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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