Sergio and the sigil

Resharper an OutOfMemory Exceptions

Posted by Sergio on 2009-02-03

My current project has an interesting story of being converted across platforms and programming languages. I hope I can talk about this conversion process some day (it was not manual).

One of the side effects of mass conversions like this is that the final result tends to carry over some weird patterns. These patterns used to make total sense in the previous programming language, but look very unnatural in the new one.

We ended up with some very large classes inside a single namespace that, while work exactly as in the previous language, cause an unusual amount of stress inside Visual Studio, especially with Resharper (version 4.1) installed. Resharper would halt with OutOfMemory exceptions all the time, until I disabled Code Analysis, arguably one of the most important features of that product.

Finally today a coworker pointed me to a fix for that. I'm still getting the exceptions if I turn on solution-wide error analysis, but I think I can live without that.

I haven't had a chance to try the nightly builds of Resharper 4.5. I have been told that those issues may go away.

UPDATE: I installed version 4.5 (build 1169.15) but it didn't help me. The only thing that changed was the layout of the error screen :) But I know my project is a tad extreme and I deserve to be punished for it.

Generated by a tool, not for human consumption

Posted by Sergio on 2009-01-30

A few years ago I had an interesting discussion with some of my then coworkers about the XML comments in our code. XML comments were useful in some cases because we were writing some libraries to be shared with many of our applications. We kept the DLLs, the XML and the CHM all in the build folder for any other developer that needed to use that library.

I know some of you have strong opinions against or in favor of XML comments. What I know is that they don't bother me but I'd trade them for a clear and self-explanatory API in a heartbeat.

But what really bothered me was when one of the guys came to me and showed this amazing Visual Studio add-on that would automatically generate the XML comments for him. I won't name the tool here because it's not important. GhostDoc (ooopsy!!!) goes through all your code, finds where XML comments can be put, and tries to guess the text of the comment from the name of the members, parameters, etc. When it finishes, a method named GetOrders will have a description "Gets the orders", a property or parameter named UserName will become "Gets the name of the user", and so on. See image below as an example.

Now, let's think about this for a second. Suppose you are trying to use a class that has a method called GetOrders, do you really need a stupid tooltip comment or a topic in a CHM file to tell you that this method "gets orders" ? Maybe you thought it would list the "orders of the gets", right? Then you bring up Intellisense suggestions and there's a property named UserName in your object, I'm sure you'd be totally puzzled wondering what it stands for, correct?

Hmmm, UserName, what could it possibly be. Ha! Thank you Mr. Tooltip you just saved my bacon. It's the name of the user. Phew, thank God I didn't need to use Reflector to figure this one out.

Sarcasm aside, what real benefit does such a tool gives you? You're just avoiding compiler warnings at most. If you want real useful content in your XML comments, they need to hand-written by someone who's thinking about the developer that will read them. A tool will not add examples, notes, tips, suggest other references, etc. Basically, if a freaking tool was able to guess what that member does, you must be able to guess it too before the tooltip comes up. The tool was not written to help the other developer. The tool was written to beat another tool (the compiler and its annoying warnings.) Use wisdom when choosing your tools. Not all of them are made equal.

What drove me over the edge to get this post out was seeing a tooltip like "Gets the name of the nick".

Uncle Bob talks Agile at Chicago ALT.NET

Posted by Sergio on 2009-01-19

After an unfortunate cancelation of our last meeting because of the weather, February's meeting of the Chicago ALT.NET Group should be a very interesting one.

Robert "Uncle Bob" Martin looks into XP's rearviewmirror, lessons learned, and the current status of Agile development.

XP: After 10 years, why are we still talking about it?

6:00 pm
Pizza and networking time

6:30 pm

It has been 10 years since Extreme Programming broke upon our industry. In that time we have seen the rise of the Agile movement, and the gold rush for Scrum certification. We have seen the concept of testing do a complete reversal in emphasis; and shift away from heavy planning. But what have we learned? Do we really all program in pairs? Do we really all write our tests first? Do Agile projects really fare better than others? Do we have enough data now to separate the truth from the myth? And why, after all this time, does it still dominate our conferences and conversations. Isn't there something new to talk about?

Robert C. Martin has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report and currently writes a monthly Craftsman column for Software Development magazine.

Mr. Martin is the founder, CEO, and president of Object Mentor Incorporated. Object Mentor is a sister company to Object Mentor International. Like OMI, Object Mentor is comprised of highly experienced software professionals who provide process improvement consulting, object-oriented software design consulting , training, and development services to major corporations around the world.

7:45 pm

Let's use the discussion time to go over the group topics that were planned for last meeting, which had to be canceled.

  • What worked well and what didn't in 2008
  • What direction should we take with our group
  • Viability of our group organizing a CodeCamp soon
  • Global ALT.NET participation: as suggested in this message

If you want to help define our meetings format and group actions, then come and help us in this discussion.

UPDATE: The videos of the event are available.

Language Envy - String Interpolation

Posted by Sergio on 2009-01-17
Language Envy: This post is part of a series where I wish C# had a particular feature I came to like when working with other programming languages.

Every time I have to produce a string in C# the little groaning chimp that lives inside my head pulls his hair out. It's about time we had a better way of doing this.

We all use string.Format to make these string concatenations more readable, but it's still too easy to get the order wrong or miss one of the argument values and get an exception. JetBrain's Resharper can be helpful here, giving hints when you have too many or too few arguments in a call to string.Format.

So what am I whining about?

When you need to create a string that mixes literals with variables in PHP (or Ruby, or Boo, or Perl, etc) it's so much easier to type, read and maintain than in C#:

<?php
	$price = 12.34;
	$product = "DVD Media";
	echo "$product costs $price";
	//ouputs: DVD Media costs 12.34
?>

Although this would be enough to get a lot done, the interpolation syntax can help with more complicated expressions beyond simple variables:

<?php
	$order = $user->getLastOrder();
	echo "The first item in the order was {$order->item[0]}.";
	//ouputs: The first item in the order was DVD Media.
?>

One interesting thing to note is that this is a syntax for combining expression values and literals. The interpolation isn't evaluated in strings that already exist and are passed in (like some user input.) In other words, the interpolation happens at parsing time, where the string is declared. The parser will not look into an existing string and replace tokens that look like variables — at least not without you explicitly asking it to do so.

In PHP the interpolation goes a little further. Just for the sake of curiosity, check this out.

<?php
	$var1 = 1000;
	$name = 'var1';
	//recursive interpolation:
	echo "The value of the variable named $name is {${$name}}";
	//outputs: This is the value of the var named var1 is 1000 
?>

Wouldn't it be nice to have such syntax in C#? The string would probably need to be taken care of at compile time, so a statement like this:

//DOESN'T WORK YET. JUST A DAYDREAM
var text = "The price of a ${product.Name} is ${product.Price}.";

At compile time would be treated as if it had been written as follows.

var text = "The price of a " + product.Name + 
           " is " + product.Price + ".";
// OR ...
var text = string.Concat("The price of a ", product.Name, 
           " is ", product.Price, ".");

Done like the example above this would be a backwards compatibility problem. I'm sure it's possible to put some symbol before the opening double quote to make this compatible.

Language Envy - hash literals

Posted by Sergio on 2009-01-05
Language Envy: This post is part of a series where I wish C# had a particular feature I came to like when working with other programming languages.

It's easy to let a small language feature go unnoticed. The more I spend time writing JavaScript and Ruby, the more one little detail shows itself loud and clear when I go back to my trusty C# (well, it shows itself by not being absent, if that makes any sense.)

The little language detail I'm writing about today is the literal syntax for hashes. Especially in JavaScript, because all objects are just hashes on steroids, which makes the literal object syntax become one and the same with the hash literals.

In JavaScript it's easy as 1-2-3. It's not surprising so many libraries are adopting hash parameters.

//Prototype.js sample
var elements = { success: 'myDiv', failure: 'errorDiv' };
var ajax = new Ajax.Updater(
	elements, 
	'getData.aspx', 
	{ method: 'get', onFailure: reportError }
	);
//jQuery sample (jQuery UI)
$('#fromDate').datepicker({rangeSelect: true, firstDay: 1});
$("#search").autocomplete("/product/find",
	{ autoFill: true, delay: 10, minChars: 3 }
	);

Now, I understand that part of the popularity of hashes in JavaScript and Ruby is due to the loose typing of these languages. But if the syntax wasn't light, APIs like the above ones would be much more painful to use.

C# 3 does have a hash syntax (or, more accurately, a dictionary one.) Unfortunately, dictionary initializers, although being a step forward, still leave noise to be removed.

// hypothetical search API 
var books = FindWithCriteria<Product>(
              new Dictionary<string,object>
              {
                {"Category", Category.Books},
                {"MinPrice", 33.45},
                {"MaxPrice", 50.00},
                {"Contains", "asp.net"}
              });

Hmmm, no, thanks. Maybe that's the reason we are starting to see some APIs that use (abuse?) anonymous objects and reflection to create hashes.

// hypothetical search API 
var books = FindWithCriteria<Product>(
              new { 
                Category = Category.Books,  
                MinPrice = 33.45,
                MaxPrice = 50.00, 
                Contains = "asp.net" 
              });

This last one doesn't look so bad on the surface, but we know what is going on under the covers so it's like putting lipstick on a pig. If, instead of using reflection at run-time, the compiler had support for converting the above anonymous object into a IDictionary<string,object>, then we would have a more convenient and efficient way of creating hashes. Maybe it's too late to introduce a feature like that while maintaining backwards compatibility.

I believe when you add a language feature that is elegantly designed (i.e. clean and unnoticeable,) it becomes popular more quickly — just like what is happening with lambdas . The existing alternatives for creating hashes in C# 3 are still too noisy or inefficient to be integrated in our code without reducing the readability or incurring a performance penalty.