I am a big advocate of coding forward.  Coding forward is the style of coding used in Test-driven development.  In TDD, we write a test as we would like the code to work.  We even allow compile errors because we are modeling the API of the code the way we would like it to read – even before it exists.  Then, we begin to fill in the holes, creating the methods that didn’t exist yet, and making them work right.

I like to carry that into all coding, not just test-first coding.  For instance, if I am in an MVC controller and I need to call a new method that I am imagining in my head, I like to just write the call to that method that doesn’t yet exist.  For instance:

Here, I know I need to make my domain model to a strongly-typed view model for use in an MVC view.  The method to do it doesn’t exist. 

A common style is to stop coding and then go create the mapping method and then come back.  I find this to be cognitively disjointed and prone to the loss of train of thought.  When I stop coding and jump down into the stack of methods & classes that need to exists for a top-level solution to work, I have to make sure I keep track of my own “call stack” or development stack of items to come back to.  If, instead, I continue coding forward to the end of the scenario, the compiler will remind me of the missing pieces because it won’t compile – or the page/function won’t run.  Automated tests do this also because the test won’t pass until all necessary code is in place.

I have noticed myself doing this, and I realized that it was distinctly a different style than many programmers.  JetBrains ReSharper does help tremendously with this style because of the navigation features and code generation features.  I’m not sure it would be as convenient without R#.  Creating a new class and then flicking it to a new code file is just a couple of shortcut keys with R#, so it’s pretty frictionless to code forward.

Happy coding (forward)