Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Laugh if you want, but I used to develop substantial line-of-business applications in VB6, long before the .NET framework came along. Why, when I was your age, we used to walk two miles in the snow, uphill. Both ways...

Love it or hate it, VB6 had a REPL-like feel, and a very rapid development cycle. I would like to know how to come closer to that process in C#. In VB6, I could write a function, execute it, debug it and have it fully functional in a few minutes. I am told this is how the Lisp crowd works. It's a very rapid-fire style of programming.

In C# I write a function, then I write a unit test for that function (which is OK, I understand the value of that), then I right-click, run test, wait for the project to compile (takes about 10 seconds right now, which would be an eternity for a REPL loop), and get an exception. Honestly, this feels more like my junior college days, when I used to feed punch cards into a hopper and wait for a printout (exaggerating only slightly for effect).

Additionally, my tendency nowadays is to make everything public while I'm testing it. Unit testing with private accessors works fine, but you can't trace through the code (unless, of course, I'm doing something wrong) while you're using them.

So what I'd like to know is, what adjustments have you made to your development process in C# to streamline it, and make it possible to write and verify your code very rapidly?

share|improve this question
3  
Have you set Visual Studio to build the projects incrementally? That can come close to eliminating the compiling step and allow you to run your code almost as fast as you write it. –  Michael K Jul 1 '11 at 16:18
    
@Michael: Is this what you are referring to? Sheesh, you'd think they would have just provided a checkbox in project properties for incremental building. –  Robert Harvey Jul 1 '11 at 16:24
    
@Robert I'm sorry, it looks like I was wrong. VS apparently doesn't have a incremental "build on save". I remapped my Ctrl-S to build. –  Michael K Jul 1 '11 at 16:37
    
@Michael: Eh, background compilation for C# was introduced in VS2008 SP1. It's the default in VS2010. –  Aaronaught Jul 1 '11 at 17:31
1  
@Robert: Tools->Options->Text Editor->C#->Advanced->Show live semantic errors. I think it's just background compilation, not background build, but you surely architect your code so that changes to core assemblies are infrequent, right? ;) –  Aaronaught Jul 1 '11 at 17:39
show 5 more comments

2 Answers

up vote 2 down vote accepted

Linqpad now has three different modes for C#:

  1. C# Expression (the original)
  2. C# Statement(s)
  3. C# Program

Although it's not a "real" REPL environment, it comes very close, and I personally have never had to tackle a problem that's too complicated for Linqpad but not complicated enough to justify proper design and unit testing. In the "program" mode you can declare types, and in all modes you can add external namespace and assembly references.

Over time I've simply adopted this as the default method of spitballing ideas, making sure that code does what I think it does (as opposed to doing what it is supposed to do, which is the domain of automated tests).

If that doesn't work for you, the Mono project has CSharpRepl. You need to actually install Mono, and there are a few vagaries to deal with, but people have done it.

(P.S. You do not need to make types or members public in order to unit test them. A better solution, which doesn't require you to remember to "fix it later", is to make them internal and use the assembly:InternalsVisibleTo attribute with the name of your unit test assembly. Visual Studio is aware of this attribute so you'll get full Intellisense and all. And you can definitely trace execution.)

share|improve this answer
    
I've been looking at Linqpad for awhile (from afar, haven't actually played around with it yet). Albahari is a genius; I love his threading tutorial. Looks like I'm going to have to bite the bullet and purchase the Intellisense for Linqpad. Thanks for sharing your experience as someone who actually uses it in a production environment. –  Robert Harvey Jul 1 '11 at 17:33
    
@Robert: I'd try out the free version first (if you haven't already) before springing for the Intellisense. I actually get by without intellisense in Linqpad, but that's probably just me being a cheapskate. –  Aaronaught Jul 1 '11 at 17:34
add comment

Its not a fair comparison to compare VB without unit tests to C# with unit tests. If you want quick turnaround dont write unit tests. Personally I think they're overrated, esp for business problems.

The other option you might want to consider is having a CI server running tests there, so they aren't in you dev loop.

Finally I like making variables public too. Especially if the alternative is just to write boilerplate get/set functions. A good thing about C# is that you can change later without affecting code that uses the property.

share|improve this answer
1  
+1 for the paragraphs on unit tests (from reconsidering the need to moving them to CI); I don't agree however with making variables public, because it's not true that promoting fields to properties won't affect other code. Just use automatic properties. –  OregonGhost Jul 1 '11 at 21:58
1  
This is all around pretty terrible advice. "Don't test business problems" -- those are exactly the ones you want to test. They're easy and important. "Keep tests out of the dev loop" -- CI is a final gatekeeper for broken code. Why check it in broken? "Use public fields instead of properties" -- until you need a property and all things compiled against your library need recompilation. That's what auto properties are for. –  insta Apr 11 '12 at 21:58
add comment

Your Answer

 
discard

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.