Follow @joshtwist

11:38 AM
20 Jul 2008

Comments are closed for this post.

Posted by Michael Giagnocavo @ 21 Jul 2008 5:48 PM
[3rd post, hope you don't think I'm trolling.]

"Often something is created without the creators realising the potential for that thing"

I sure hope that's not the case here. Type inference has been around for decades (and much more complete than C#'s). I'd hope people hired by MS would have background to know about these things ;).

If you want to see how this worked out, no need to wait a year. Go checkup on languages that have implemented this. The Wikipedia entry on type inference has a list of languages.

Posted by redsolo @ 22 Jul 2008 3:11 AM
If people are saying they "var" every variable because its so much easier to read and write. Why not go the full monty, and removing the var declaration completly?

For me the reasons to use var are the reasons why it never should have been added.


python lets you do this:
x = 6
y = 5
z = x + y

and that is even more short/simple than
var x = 6
var y = 5
var z = x + y

Posted by Michael Giagnocavo @ 22 Jul 2008 10:45 AM
Because then you run into the issue of:
productComposite = 123
...
if productcompsoite > 0 then

Of course you can get around this by making all variables read-only. Then assignment equals declaration.

What's funny is that the those who hate "var" still use "let" inside query comprehensions and don't bother specifying the type of each parameter when using a lambda expression.

Posted by Brian Johnston @ 30 Jul 2008 5:09 PM
Forgive my stupidity...

so in python

x = 7
y = 5
z = x + y
z = z + 4294967296

Does z magically change from an int to a long (or whatever Python equivalent is)? Or do you get an overflow exception?

So not working with primitive types...looking at the following code what am I doing? And I'll take it to the Python extreme.

z = this.Account

c = Customer.Get(75234);
if(c.Account == null)
{
a = Account.Get(c.AccountId);
}

z.Account = a;

Answer to come later...but I'll give you a hint, I'm not creating an account for a customer.

Oh, and yes, I work with people that write code that is this readable with 0 comments. Certain co-workers of mine send out 'code of the day' emails to each other for laughs - so don't think that this isn't a reality or an extreme example.

I'm all about readability and maintainability. The code above (non-primitive types) is a good example of being neither. If I threw this at you and said debug it...where would you start? The poll on 'var' was easy for me.

So guess folks, please....

Posted by Brian Johnston @ 30 Jul 2008 8:01 PM
To follow up, in the above if I use type declarations (again I run into this stuff daily, I'll add comments to decipher):

ContractAccountControl z = this.Account

//Get the specified contract for the customer and
//and initialize the account object if it hasn't been
Contract c = Customer.Get(75234);
if(c.Account == null)
{
Account a = Account.Get(c.AccountId);
}

//Set the control Account property to the account
//for the contract
z.Account = a;

----

So yes I know there is a glaring bug, but that aside, my point that I'm showing is that without the type declaration, you don't even know you're working with a contract where the account for that contract is being displayed as part of a GUI control.

It could be argued that one would've figured this out if they had the context of the whole file - but that's not my point.

My point is that 'var' leads to developers who already write non-self-describing code that is barely maintainable to developers who write even worse code.

For those of you who will say this is a training issue or management issue, etc, then you must be blessed with being in shops where those things are an option, you need come join some of out here it was appears to me at least as very good size chunk of the world where people don't care about quality, they care about quantity because there business is to make money through means that have nothing to do with writing software (i.e. ITS) and despite what you want to believe, you are not there to write software, you are there to solve business problems and automate solutions and if cowboy coder Z can sling this crap and get it out there quicker, then 4 out 5 times, he's going to become the defacto lead developer...but that eventually trips up on itself and well anyway I'm digressing...

I work with several good developers, but I've also inherited some code written by rushed developers (don't know whether they were good or not, but I can tell by the code that they were rushed), and seen other code in previous stints that makes this code look very clean.

For example, imagine if you will combining the ability to 'var' items with clever variable names like axrfvo that is nested inside of a if statement that is nested inside another if statement that is nested in a for loop that is nested in another for loop that is nested in an if statement. This is what I deal with.

Yup, my job will make you a master of refactoring.

Posted by Jeremy Gray @ 14 Aug 2008 11:49 PM
Having just discovered this post today through some link way back there in my history, I feel compelled to call BS on Brian:

var vs. lack of var isn't your problem here. Variables like 'z' are your problem, as are properties like "Account" (which wasn't an account, it was a ContractAccountControl.)

If you're going to set up an example to either knock down var, or knock down implicit declaration, or whatever it was that you were actually trying to do (since it wasn't all that clear even after reading your posts a few times) you might want to use an example that won't cause people to immediately write off your arguments.

Posted by Michael Giagnocavo @ 15 Aug 2008 12:55 PM
@Brian: Jeremy is right. Saying that it's a training issue and you can't train is irrelevant. This is because if you have a process to stop people from using var (code review), then you'll have a process to stop people from writing dumbass code like that sample.

And on top of that, your argument is really only against stupid/poor developers and their organizations.

Using your logic, you can contrive all sorts of things. Here's a conclusion: "programmers should have to work in public spaces where I can easily see their monitors". Argument: Our developers suck so much they just surf Fark all day, and that's how this org is and we can't change that. That's not an argument against private workspaces, that's just a poor situation.

Posted by Ellis @ 29 Aug 2008 1:16 AM
"you need come join some of out here it was appears to me at least as very good size chunk of the world where people don't care about quality"

Sorry, I just thought that sentence was ironic :)