7 Features I Wish C# Had

A while ago I saw StackOverflow question What enhancements do you want for your programming language?. I was able to, to my surprise, actually come up with something, but to be honest I don’t really think very much about what in my current programming language should be changed. Don’t get me wrong, I bitched and moaned about Visual Basic for about a decade, but it wasn’t that I wanted VB ‘changed’; I just didn’t want to work in it at all. But I digress, actually, you may want to avoid me if I ever get on the topic.

This question about what I would like to see in a programming language is something I’ve thought about, since, but the only real features I can think of consist around building a domain specific language around a specific industry and methodology. I think it would be cool to build a language around a technical analysis technique called Elliot Wave for example.

More recently, I’ve heard Jeff Atwood assert, on the StackOverflow podcast, that any good programmer can whip off 10 things they hate about their favorite programming language in a flash.*

I couldn’t come up with 10 things I hate, so I’m going to settle for 7 features I’d like to see. There may be good reasons why we don’t have some of them, but here’s my list anyway:

1. Parameter constraints

One of the first things I learned to do when I started programming, is to validate the parameters. This has saved me untold hours of debugging and I currently start every method with something like:

void DoSomething(float percentage, string userName)
{
	if (0 > percentage || 100 < percentage) 
		throw new ArgumentOutOfRangeException();
	if (string.IsNullOrEmpty(userName)) 
		throw new ArgumentNullException();
	if (0 > userName.Length) 
		throw new ArgumentNullException();
	if (userName.Equals("Guest")) 
		throw new ArgumentException("User must log in.");

	// .... do stuff
}

This is in almost every method. So why can’t the language do this for me automatically?

Yes, I know about declarative programming, but isn’t that just pushing it into the attributes? Where a 3rd party tool will process it?

What I’m suggesting is something similar to the generics keyword ‘where’. Why not have something like this:

void DoSomething(float percentage where 0 <= percentage && 100 >= percentage, 
		string userName where !string.IsNullOrEmpty(userName) && 20 >= userName.Length && !"Guest".Equals(userName))
{
	// .... do stuff
}

Really complex validation rules could be separated into its own function or you could always fall back to validation in the body of the method the way we do it now..

2. An ‘IN’ operator

I find the following code a bit redundant:

if (x == 1 || x == 2 || x == 3 || x == 5 || x == 8 || x == 13)
{
	// .... do stuff
}

I’d prefer to borrow the SQL keyword and just write

if (x in (1, 2, 3, 5, 8, 13))
{
	// .... do stuff
}

EDIT: Apparently SecretGeek already created a class for SQL Style Extensions for C# which does exactly what I wanted (for strings anyway). Thanks Darrel Miller for the link.

3. A 3 way between operator

I’ve always wished we could replace

if (fiscalYearStartDate <= currentDate && currentDate <= fiscalYearEndDate)
{
	// ... do stuff
}

with

if (fiscalYearStartDate <= currentDate <= fiscalYearEndDate)
{
	// ... do stuff
}

4. Only allow var on true anonymous types

var adds awesome functionality to C#, like the ability to create anonymous types from an expression. However, when I start seeing code where all the variables are typed ‘var‘ I get a little worried.

Now I know about type inference and that var is the same at run time as explicitly stating the type, but when you want to look up what the heck variable x is; it’d be nice if the variable definition would tell me

ObjectX v = new ObjectX();

instead of

var v = new ObjectX();

I also realize, I can figure out the type by looking on the right side of the assignment operator and in the above example above it’s pretty darn clear exactly what type v is. But what if the expression is a method?

var v = DoSomething();

Now I’ve got to look up the definition of DoSomething().

Not a big deal, but you’re already 2 definitions away from your core task. This is needless resistance as far as I’m concerned.

Well, you say, I could just use intellisense to hover over the method to get the method’s return type. That is true, because, thank god, the return type for a method (along with parameters) requires the type be specified, so I can get the method type from intellisense with only one definition source code jump. However, this logic is flawed because if the type was used instead of var, intellisense would have told me without any source code definition jumps what the type was. Rather than the useless “(local variable) object v” tip I receive with it.

You know, I am pretty anal about this type of thing, and NO, I haven’t had a real world problems yet, but it just feels wrong.

5. Constant methods and properties

One of the features I always used when I coded in C++ was constant functions. The great thing about constant functions is they prevent side effects. So you know if someone, like yourself, alters functionality which is not expected to change anything, has a side effect, it won’t compile and will have to be dealt with.

This isn’t the most popular functionality in C++ and while this concept helped me write bullet proof code on my own, when I started working on a team, they weren’t very thrilled with the keyword and quickly removed it. But hey, that’s kind of a tell isn’t it?

To be honest, I don’t usually have problems like this with projects I initiate. This may be irrelevant with good design, but I would like the peace of mind in having it anyway.

6. JIT properties without a local variable to cache the value

Remember how you’d need to create a local variable for every property you create? Like:

private int _id = 0;
public int Id
{
	get {return _id;}
	set {_id = value;}
}

Which became

public int Id { get; set;}

But what about properties with JIT functionality or have a side effect? Something like this, seems awfully unfair:

private int _nextId = 0;
public int NextId
{
	get {return _nextId++;}
	set {_nextId = value;}
}

Why not have something like a thisProperty keyword? Something like :

public int NextId
{
	get {return thisProperty++;}
	set;
}

7. Warn command

I’m not talking about the preprocessor #warning. I want something like throw, but without interrupting program flow.

Why? Lets say your data access layer pulls a null or otherwise unexpected value out of a database for a value which should have a very specific set of values.**

This is recoverable and no big deal, you use a default value, but you might like to somehow warn the user this was done. So; you can’t throw an exception since that would interrupt your program flow, I can’t think of any framework component you could add***, you could add some external dependency I suppose, you can build your own external dependency which all future apps will require, you cannot use one of the GUI level features like Session since it wouldn’t be available from the DAL DLL level, and you definitely don’t want to add parameters to every method so you can pass some warning collection up & down the stack!

But something like a warn command looks awfully elegant!

warn new UnexpectedDataWarning("Unexpected status code. Set to 'Open'.");

Then in the GUI level, you can traverse the warnings collection and display them to the user.

* I can’t figure out which episode it was, so no link. Please comment if you know. Thanks.
** Yes, the database should have constraints, but sometimes things are not under your control or perhaps you have a logical reason to not create constraints … but that’s another post … probably early next week.
*** At least I don’t know of anything. Please let me know if there is something built into core framework which would allow this.

Copyright © John MacIntyre 2010, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

Twitter users need a Valet Key for 3rd Party Tools

I’m noticing a lot of Twitter tools requiring the user to enter their Twitter user id and password to use the tool. These tools obviously need the users’ credentials to access the Twitter API and act on behalf of the user.

But am I the only one who is uncomfortable with this? I mean, isn’t the first rule of passwords not to give them out to anybody? Isn’t it?!?!?

Instead it’s become the acceptable practice to enter it into every app requesting it! Correct me if I’m wrong, but as far as I know, you can’t use TweetDeck, StockTwits, or Twubble without entering your Twitter credentials, just to name a few.

Now you may say, the risk is low … I mean who really gives a hoot if my Twitter account gets hijacked? I’ve currently got 91 followers, many of which are social media experts looking for reciprocity follows anyway! Who cares? Nobody’s listening! Maybe so, but all it really takes is one follower who trusts me to go to a phishing site and act on ‘my’ recommendation. The risk is high enough for me.

The stakes are even higher for users with larger followings. Do you think Ashton Kutcher, with his 933k followers, doesn’t use any of these tools? Do you really think he’s using the basic web page? I doubt it.

…. maybe I’m being paranoid. After all, I have zero qualms about entering my sys admin credentials into my database tools. Currently I use Microsoft tools to access my SQLServer databases, so there is a bit more trust, but I still wouldn’t have a problem entering my credentials into TOAD to access an Oracle database.

My fear is that as more web applications attempt to expose their API’s to 3rd party developers, this unsafe credential divulging scenario will only proliferate.

What is really needed is second tier Twitter access. Like the valet key for your car, you can hand over the keys to the valet, but they can’t pop the hood, get in your glove box, or steal the golf clubs out of your trunk.

It’s late and to be honest I don’t immediately see any good way to handle this, but here are some initial ideas:

1. A second lower tier password specifically for 3rd party tools
2. Having the tool redirect to some kind of Twitter log in page, hosted on Twitter, which would then return the user to the tool web site, while providing access in the name of the user.
3. The ability to log into Twitter and get a temporary or permanent ‘application key’, which the user could copy & paste into the tool.

Option 1 and 3 both kind of suck, with 3 adding any extra cumbersome step, increasing resistance and dropping adoption of these tools.

The interesting thing is that option 2 already exists! Twitter already has a valet key called ‘OAuth’, there’s even a FAQ and sample code to help developers incorporate it into their software.

WeFollow is currently using it. If you go to their home page (do people still say home page?), click on the ‘Add yourself to WeFollow’ image, you eventually get sent to a Twitter authentication page. Once you authenticate yourself, and you get sent back to the WeFollow site. This is nothing new, and is used in PayPal and MyOpenID just to name two. Later, you can go into your Twitter Settings, select the Connections tab, and remove WeFollow from having access if you want to.

This doesn’t really work well with a desktop application, since the browser would probably end up being embedded right into the desktop app anyway, which doesn’t really have the detached neutrality feel of a 3rd party web browser does it? So some type of valet key for the desktop apps would still be preferred, but in truth, I feel a lot more comfortable entering my credentials into a desktop app, than an unknown website any day.

The real question is; why aren’t all the other web apps using OAuth? Why does StockTwits require their users to enter Twitter credentials into the StockTwits website instead of using OAuth?

Why aren’t their users demanding it?

EDIT:Brent Ozar has indicated that OAuth is fairly new and many sites just haven’t finished factoring it into their user model yet. Thanks Brent.

Copyright © John MacIntyre 2009, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.