Thinking about code

[andrewducker]

  If I have a method:
int DoSomething(string someStuff)
{
  //Do Stuff
  return 42;
}
then effectively I have an unnamed variable that gets set by the return statement, yes?

That being the case, wouldn't it be in some ways clearer to have an explicit, named, variable that gets set instead?

int DoSomething(string someStuff)
{
  //Do Stuff
  returnValue = 42;
}

where "returnValue" is a keyword that's used to return the value.

As it is I frequently end up with code that creates (or sets) a variable at various points through the code just so it can be returned at the end.  Making this an explicit part of the language just makes sense to me.

I assume there are languages out there that do this.

Comments

[andrewducker]

What's so complicated about that line?

I can separate it out into:

MessageList myMessageList;

myMessageList = new MessageList();

Where the first line says that there is a variable called myMessageList of type MessageList, and the second line puts a new MessageList into it. But the combination is more compact.

As to not declaring variables - I'm not giving up the massive benefits of statically typed variables - including IntelliSense, refactoring support and that compiling the code tells me whether I've spelled anything wrong, or got my types confused.

[momentsmusicaux.livejournal.com]

Yes, but it's called the same as its type! Arg! And you are having to repeat the type name -- that's a total violation of DRY, surely.

For that matter, why do you need a type as specific as a message list? Why is that not just an array?

[andrewducker]

Aaaah, because in the case of MessageList (at work that is) MessageList.Warnings returns just those messages that have a MessageType of Warning, while MessageList.Errors returns just the errors, etc. Utility methods are very handy :->

In C# 3 I can actually say:
var myErrorMessages = new MessageList();
and it will use type inference to work out what type it is at compile time.

[momentsmusicaux.livejournal.com]

Ah, so it's an object rather than just a data type? I can see that would be useful.