The way programming should be - easy

As developers, we spend most of our lives writing code - eight hours a day (usually more) at work; perhaps a few more hours at home and on weekends. In this kind of situation, a single incremental improvement in how we write code makes huge differences over time to our productivity, over all well being, and chances at achieving moksha.

In an ideal world we'd move ideas into code on a computer using our minds. We'd like to treat our code like putty, to be shaped into whatever our minds can imagine - and then reshape it as requirements change, of course :-).
Unfortunately, this isn't an ideal world, so we're forced to use the keyboard and mouse but we should never stop aspiring to the ideal of code-as-putty.

There are two common routes to this ideal, given that we're stuck with keyboards and source files:
  1. the syntax and semantics of the language itself
  2. tool support
Clearly, both help make life easier and just as clearly the level of tool support needed decreases with improvements in the language. That said, I'm yet to come across a language which wouldn't benefit from some amount of tool support. Remember, we're talking about incremental improvements, not silver bullets - a better 'rename' which ensures syntactic consistency is definitely an improvement over regexp based find-replace. Obviously, everybody has a different idea about which languages and tools improve productivity and to what degree, just as everyone has a different opinion about what constitutes 'well being'. This shouldn't prevent us from constantly moving to languages and tools which make our lives easier, yet I never see tools being discussed except during the odd flame war. We have come a long way since we crossed refactoring's rubicon in Java seven years ago, yet how many posts do we see out there about how we can do more with tools today?

Sometime ago, I'd posted a rant calling VS2008 a piece of crap. In his typically polite way, Ramesh pointed out in his post that provocative titles and rants aren't always the best way to convey one's message. He's absolutely right. So to that end, I'm going to start posting productivity enhancing IDE tips and tricks I come across as I write code every day. Posts will be short, something I can compose when I'm taking a break and getting a cup of chai or some fruit juice in the pantry. Three lines of text, a couple of screen-shots, that's it.

To start with it'll be all in VS2008+ReSharper as I'm currently developing in C#, but I intend to continue this series as I move from one language to another - and I welcome any suggestions or improvement anyone may have, whether it's Lisp, Erlang, Java, Ruby or C#. Anything which makes the lives of those on those platforms that little bit easier :-).

A little tidbit to get started - smart code complete when filling in parameters.

If you're using a method which takes a bunch of parameters, here's a quick way to fill them in without having to look up the param list for that method. Just position the cursor inside the brackets and hit Ctrl+Shift+Space and you'll get the most plausible option from the variables available. ReSharper looks at the types and names of variables in scope at that point to do this and is almost always accurate. Instead of looking up docs, you simply hit Ctrl+Shift+Space a few times and your parameters will be populated. In the shot above, even though all the parameters being passed are strings, ReSharper correctly guesses their order based on variable names.

ReSharper also helpfully pops up the parameter list in cases where methods are overloaded to help you decide how many times you should press Ctrl+Shift+Space.

2 comments:

rams said...

Very good first post in your new series. I like how you beautifully segued into your tip with the great introduction. I have read about ReSharper but had no opportunity to work with or get a buy in from "the powers that be" to use it. However I currently am in a position to better influence decisions. Your tip about the method parameter filling is a great way to convince a "newbie" to take a look @ Resharper.

I think your experience with multiple languages, platforms and development methodologies can bring a better insight into these kind of tips and educational posts.

What attracted me to your blog was your straight talking and not being afraid to call an ugly baby ugly ;-) Keep these useful tips coming and the others as well.

Good work.

Anonymous said...

I agree with the sentiment that programming should be easy.

As programmers we should NEVER accept the fact that coding is hard. It shouldn't be, unless you are a masochist of course heheheh.

The HARD part should not be in the programming but the design.

I'll give a concrete example. The framework RoR (Ruby on Rails) gives excellent error messages pointing me to EXACTLY where my errors are occurring. That way I can actually DEVELOP and MARKET my software instead of DEBUG and DEBUG my software the entire time.

Also I hate VC2008. I have to use it for C++ now and it is an insane nightmare.