2

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.

1

5 Answers 5

4

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 ASP.net I think your code should be very modular, well split, and easy to test.

3
  • 1
    Yea, I write test first then the code needed to pass the test. Commented Mar 22, 2011 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
    Commented Mar 22, 2011 at 18:32
  • any asp.net test before code tutorials?
    – Spooks
    Commented Mar 22, 2011 at 21:37
2

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.

1
  • 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. Commented Mar 22, 2011 at 18:12
1

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.

1

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

1
  • I'd probably add Code Complete to that book recommendation as well.
    – Brandon
    Commented Mar 22, 2011 at 20:19
0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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