Laugh if you want, but I used to develop substantial line-of-business applicatio
ID: 642814 • Letter: L
Question
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?
Explanation / Answer
Linqpad now has three different modes for C#:
C# Expression (the original)
C# Statement(s)
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.)
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.