Posts in  resharper

4.17.2014

Video: The Value of Consistently Formatted Code

Tabs or Spaces, the age old debate that will likely never be settled! Fortunately, at the end of the day consistent formatting is more valuable than the rules we follow because consistency significantly improves readability and maintainability.

4.23.2013

The Value of Using ReSharper with Visual Studio

ReSharper is an absolutely fantastic complement to the Visual Studio development experience that provides immense value. It's a requisite in my day to day work with Visual Studio. In many ways ReSharper features form the basis for the criteria I use when evaluating a development environment for any platform.

ReSharper helps me reduce bugs.

Many bugs can be avoided with good automated testing up front. Testing also helps prevent recurrence of bugs. One barrier to testing is the wide variety of tools and the lack of integration with development environments. This barrier decreases the dividends testing can provide and justifiably in some cases costs more than it is worth, or at least mentally seems to.

ReSharper lowers this barrier by providing integration of a consistent test runner. Out of the box it supports NUnit (one of the oldest .net testing packages) and MSTest from Microsoft. Plugins can provide coverage for other frameworks. Recently ReSharper even added support for testing JavaScript via QUnit and Jasmine frameworks! The testing tools are one of my absolute favorite features. I can run a test or set of tests with a keystroke and get results in an integrated, visually appealing test runner. Running tests with this level of granularity and integration is a very rare feature in testing platforms. It allows me to thoroughly test components before assembling and testing the entire product.

If I have a bug in existing code, features like Stack Trace Explorer make it easy to track down and identify the issue.

Lowering the barrier to testing makes automated testing more economical versus manual verification. At the end of the day I can work faster and the resulting product is more reliable. In my opinion, this testing integration alone covers the cost of the license. I save at least 2 hours a week using automated testing with ReSharper over F5 debugging. It also leads to at least one less production bug a month and gives me immense confidence in what I do allowing me to work even faster.

ReSharper helps me maintain code and avoid "re-writes"

Poorly maintained code is difficult to change, difficult to understand and in some cases difficult to read! This is often referred to as spaghetti code. These design problems lead to stagnant progress evolving a software product to the ever changing demands of business. Writing, understanding, maintaining and evolving software is hard work and is often tedious.

ReSharper reduces repetitive and tedious tasks evolving code by providing a plethora of automated refactorings. It's challenging enough to decide WHAT refactoring to apply, let alone to carry it out. Most beneficial refactorings can be automated and ReSharper does just that with integration and shortcut keys! Having these tools available at a keystroke means I don't wait to change code that is troublesome. ReSharper allows me to avoid the need for a "re-write" by continuously evolving the code to meet the needs of business. Paired with easy automated testing and I have confidence that my refactorings aren't introducing bugs!

Maintainable code means I don't have to worry about re-writes, ReSharper can even help tackle the worst of spaghetti code and evolve it to something more maintainable over time. The costs and risks in a "re-write" are phenomenal. Day to day refactorings save me at least an hour every week manually refactoring my code and it expands my ability to do so. Continuous refactoring also reduces the likelihood of a delay from code that is difficult to change.

ReSharper helps keep my code consistently formatted

Style preferences aside, most developers agree consistency is a good idea. Each project often has a particular style that is an artifact of the time it was created in. Often there's no reason to change the style, but it can be extremely difficult to enforce it when I adopt new styles.

ReSharper allows me to setup shared settings for multiple machines or when I work on teams. They are applied hierarchically so I can have whatever level of consistency I desire. These settings allow decisions in the past to be enforced via simple Code Cleanup commands and don't require me to spend time worrying if I am following consistent rules for any particular project. Instead, I can focus on the content and get consistency for free!

I save at least 30 minutes each day, I know this because I use the silent cleanup ctrl+e,f immediately followed by ctrl+s and find myself doing it in applications that don't support it :) If I stumble on code that is inconsistent, I setup rules and apply cleanup as needed to get a better idea of what it does.

ReSharper helps me comprehend code faster

As systems grow, so does the code behind them. This can become difficult to organize and even more important to navigate. Folders and projects only go so far and the Solution Explorer is a very crude way to get where you need to go, it's not very keyboard friendly! I spend a significant amount of my time reading code, so having a barrier to navigation is extremely unproductive.

ReSharper provides a bevy of features to ease navigation. A single Navigate To shortcut with contextual support can get me where I am going quickly. The Go to Type, Go to File and other Go to features make searching and jumping to any place in code lightning fast. ReSharper even supports integrated decompilation and navigation with dotPeek. Paired with refactoring and testing, superb navigation further allows me to evolve and comprehend code.

ReSharper also makes identifying unused code with solution analysis a simple task and helps remove it with Safe Delete. Unused code just leads to confusion and begets more unused code!

Every day I navigate to different places in my code 100s of times, ReSharper provides features that shave multiple seconds off each navigation, the amount of time is incomprehensible, at least 30 minutes every day, and that's only estimating about 4 seconds saved per navigation, it takes longer than that to do anything with the solution explorer and a mouse.

ReSharper helps me type less

Even the best of languages can be verbose, C# is not immune and wow is all I can say about Visual Basic. Why should I spend time typing syntax when I could be focused on content?

ReSharper provides many completions to make writing code less burdensome. It also supports several levels of templating and generation to reuse common patterns. These templates are customizable and can be shared with other team members with ease. One of my favorite templates is a test method snippet. When I want to add a test I don't have to type the scaffolding, I can focus on the content. I write more fine grained tests because of this which increases maintainability of my tests! I also thoroughly enjoy code generation of method declarations so I can focus on what the method does!

Less typing saves me even more time every day, at least an hour a day versus manually typing everything out, the biggest savings is in avoiding compilation and other mistakes that shift my focus from content.

Summary

Of the above, which are by no means comprehensive of the value I get out of ReSharper, I've enumerated a savings of at least 13 hours per week. That's time I re-invest in content instead of tedium. This is likely a conservative estimate as I feel my productivity is more than doubled with ReSharper.

If you are a developer, what would these savings mean to you? If you fund development teams in your company, what would these savings mean for your company?

3.18.2013

Nebraska Code Camp 3 Recap

Thanks again to everyone that came to my workshop and presentation.

You can find the content of the presentation here:

https://github.com/g0t4/Presentations

I've added a tag for nebraskacodecamp3 in the event I reuse and continue to modify these presentations in the future.

Async Programming in Javascript with Await and Defer, look in JavascriptAwaitAndDefer. I exported my google doc analysis spreadsheet to an html file and checked it in too.

HALF DAY WORKSHOP: Introduction to Refactoring with Resharper, look in RefactoringWithResharper.

3.12.2013

Teaser: HALF DAY WORKSHOP: Introduction to Refactoring with Resharper #ncc3

9.24.2009

The slippery slope of "var"

The var keyword has been a rather controversial addition to the C# language. Many developers initially fear it, getting lost in demos that use it. Eventually, they come to understand it as something "lazy" programmers would use and often dismiss it. I've gone through these stages. I even remember my blood boiling when I saw resharper, out of the box, suggest to use it! I never really understood it as anything more than implicit typing.

Recently, I decided that I should learn new concepts with new languages instead of just trying to learn and do examples in the same old. Why not kill two birds with one stone! I've been exploring a lot of interpreted languages (functional and imperative), focusing on Scheme (LISP) and python. I've had a great joy reading and conceptualizing new things in these language.

Studying new concepts and applying them with dynamic languages has made me notice, more than ever, all the boiler plate type code to get anything done in C#. After a weekend of hacking in python, I find myself skipping type declarations in C# only to get compiler errors :(. The simplicity of

names = ('Bob', 'John')
in python is doubled in C# to
List<string> names = new List<string>{ "Bob", "John" };
without any added value!

I have been struggling to find ways to bring this simplicity to C#, short of switching to python altogether :). My favorite way is to cut some of the crap and go with
var names = new List<string>{ "Bob", "John" };
. No loss of information and some added clarity! However, the use of var is often frowned upon as if it were unprofessional, my peers reading my latest code only to comment on my "abuse" of it!

What I was missing is the next step in the progression of understanding var. I was starting to realize that it adds clarity through readability! No longer do I have to scan through a bunch of type verbiage in a variable declaration to find the name, let alone the content. Readability alone wasn't convincing my critics so I pondered on the topic some more in regards to another set of concepts I have been working to grasp, DDD.

In studying DDD (Domain Driven Design) I detected a sense of deja vu. The core concepts, of creating a ubiquitous language and model that permeates code, was resonating all the way down to the level of variables. If a variable represents a list of employee names, it should be labeled employeeNames. If we cram that much intent and meaning into our variable names, why do we even care what primitive or compound type is used?

employeeNames might be implemented as a List<string> in C# or a simple list in python. However, when all is said and done, employeeNames is neither a List<string> in C# nor a list in python. Thinking about it as such adds no value, just translation overhead. employeeNames is simply a variable to store employee names, it's type is employeeNames! The name implies this directly. It describes a kind of name, employee, and it's plural, clearly a collection or set of names. The same would apply for a variable to represent age, even if implemented as an integer, it's not an integer, it is an age!

I think this is the answer to help convince people that using var is actually a good thing. Especially when writing unit tests where readability is a primary concern. I would even go so far as to suggest using it anywhere when declaring a variable. The only argument I have heard against this, thus far, is that this will lead to ambiguity. But wait a minute, I think the opposite is true! Static typing leaves room for intention to be left in the type itself. Because of this, developers get sloppy with variable names. When developers don't have a type to prefix a variable, they typically put more intention into the name, for their own sanity!

I would be more inclined to believe I would run across
List<string> employees = new List<string>();
in C# than
employees = ('Bob', 'John')
in python. This example requires knowledge that employees is implemented as a list of strings for someone to extrapolate that employees holds names and not ages or something else. However, with a list of strings, this may just be a guess! It could be a list of their emails or maybe home addresses! I know I've seen this in the past and I know I've done it myself. This added translation only decreases the maintainability of the code.

So the next evolution, in the slope of understanding and using var will be understanding it as a tool of readability and to help avoid leaving intention in types. This adds a layer of linguistic abstraction that hides the implementation of our variable's type and makes it more flexible.

I think the last evolution with var, will be to help developers get more familiar with the ideas behind dynamic typing. Implicit typing is like a step in the direction of dynamic typing. The last thing to do, seems to be to drop the use of var at all. It's simply linguistic boilerplate to developers (even if it serves a purpose to the C# evaluator).

So get your var on, don't be ashamed!

8.21.2009

My cool code snippet

I submitted this to the Resharper cool code snippet competition and thought I would share it with everyone else, including why it’s cool!

[Test]
public void $METHOD$$SCENARIO$$EXPECTATION$()
{
  $END$
}
I’ve been doing a lot of TDD lately and I am constantly writing new tests. So my number one snippet is one that creates a simple test. I’ve tweaked this template a lot, it started out with a simple test template with only one editable occurance for a name. In “The Art of Unit Testing,” Roy Osherove talks about test readability which starts with the test name itself. He suggests putting the test method name together with three components. First, name the method under test (the Act in AAA), that way related tests for the same method are easy to identify (and actually R# sorts test fixture test methods by name so this is even more useful with Code Cleanup :) ). Second, name it with a scenario, what is unique about the given context of the test (known as the Arrange in AAA). Finally, include the outcome of the test, the expectation (Assert in AAA). This way you know all of what will go into the test before you write it!

I gave his naming scheme a try and found out it offers a pit of success. If you cannot name these three parts then your test likely won’t be readable. Anyone should know what a test does without reading it, like with any method, it should be intention revealing! Without identifying a scenario explicitly, it may be blurred in several lines of setup (Arrange). Having the scenario in the name makes it explicit and makes me keep it simple (I hate long method names). The test may have too many expectations, again, I hate long method names so if I find myself putting multiple expectations in the name I will quickly realize I need to move the other expectations to new tests (SRP with testing)!

The same day I tried using this test method naming convention, was the same day I created this test snippet and have kept it ever since. Every time I write a test, I am very explicit and careful, which is very important with TDD, not to take on too much with any one test!

This snippet is awesome, not because of the code it creates, but because it sets myself up for success every time I use it, like having Uncle Bob Martin watching over my shoulder :)