Not programming, but a preference question.

[Jorgen Andersson]

wizardzz wrote:

A big ugly word

Small and ugly I would say.

wizardzz wrote:

So does it make me a dick to want to use some sort of Hungarian Notation* on these vars?

Sort of, it has a distinct feel of VB6, but atleast it doesn't make you a Sunshine.

Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions

[TheGreatAndPowerfulOz]

Jörgen Andersson wrote:

make you a Sunshine

But if it did, then he could elephant himself.

If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun

[Tom Delany]

AspDotNetDev wrote:

var varBinks

Wasn't he JarJar's step-brother? :-D

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.

[Tom Delany]

wizardzz wrote:

am I dick for changing variables to make more sense?

No no. Not just for that. ;P Don't get your undies in a bundle. I'm just busting your chops! :)

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.

[Tom Delany]

Espen Harlinn wrote:

I'm pretty sure other refactoring tools have a similar feature.

Resharper does.

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.

[Tom Delany]

Pete O'Hanlon wrote:

IT doesn't make you a dick.

Damn! you beat me to it![^] :doh:

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.

[PIEBALDconsult]

ahmed zahmed wrote:

var should only be used where the type can be easily ascertained

No, that's wrong -- it should only be used when the developer can't know the type, as in

ahmed zahmed wrote:

when using LINQ

[BillWoodruff]

Hi Colin, Excuse me for being picky-picky, but, in your first code example above: I can see four reasons why it will not compile (errors) just by eye-balling it. To my mind, two of those errors reflect a mis-understanding of the required syntax/semantics for how 'var can be used. I see no reason to down-vote here (or up-vote), because you are, after all, posting this as a "theoretical example," not "working code," but, also, I must admit by being "disturbed" that two different classes contain a sub-class (RequiredComponent) with an identical name: that practice, to me, is one that may give rise to problems with later code maintenance: if "RequiredComponent" is ever used from outside its parent Class(es). best, Bill

"The greatest mystery is not that we have been flung at random between the profusion of matter and of the stars, but that within this prison we can draw from ourselves images powerful enough to deny our nothingness." Andre Malraux

[BillWoodruff]

My 2 cents (farthings, groats, obeloi) worth: While MS pronouncements on use of 'var have often mentioned the "economy" of not having to enter the fully qualified name of some object twice: imho, the major usage has been associated with conveniently storing the result of some LINQ-produced complex entity that you could break a tooth on trying to specify its exact type. ... begin edit #1 ... And, I forgot to say using 'var for "anonymous types" is required ! ... end edit #1 ... We've always had ways to shorten up long fully-qualified object names using the "using directive:" as in the "extreme" example offered here:

using System;
using spc1 = ThirdPartyNameSpace.RequiredComponent1;
using spc2 = DifferentThirdPartyNameSpace.RequiredComponent2;

namespace ThirdPartyNameSpace
{
// used internal here just for the 'hell' of it ...
internal class RequiredComponent1
{
}
}

namespace DifferentThirdPartyNameSpace
{
internal class RequiredComponent2
{
}
}

namespace Local
{
class Thingamajig
{
spc1 s1ReqComponent = new spc1();

    spc2 s2ReqComponent = new spc2();
}

}

Note that I am not advocating you should code this way, and, in actual practice, I usually use this only when using a 3rd. party component that really requires complex multi-dot path names to use the most commonly used elements in it. And, in that case, I would use variable names that were, indeed, mnemonic (which is not what you see here). best, Bill

"The greatest mystery is not that we have been flung at random between the profusion of matter and of the stars, but that within this prison we can draw from ourselves images powerful enough to deny our nothingness." Andre Malraux

[Member 4194593]

Ar the risk of being down voted to oblivion, I always use HN on all of my variables. Came from coding for a system that used Capital Letters for system defined values, and Lower Case letters for local variables, and hot and heavy Code Inspections which enforced the practice (inspectors with an attitude). Even now, where I am a hobby MASM coder, I use the same notations. Dave.

[walterhevedeich]

Collin Jasnoch wrote:

I am quite certain I will ge downvoted for this post

I'm quite certain you're wrong. You're just giving your opinion, not forcing him to do it that way. After all, sharing ideas is what this forum is all about.

Signature construction in progress. Sorry for the inconvenience.

[Paul Conrad]

wizardzz wrote:

I don't use them unless I really need to

I don't either, and in my shop they are not allowed. Part of my coding standard I enforce :rolleyes:

"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

[Lost User]

Hmmm pretty sure it is fine. For one they are not subclasses. They are classes within a namespace. This is a common confliction when working with many groups or using external resources, E.g Company a has "Camera" in their library as well as company B. So we end up with CompanyA.Camera And CompanyB.Camera For objects. That was actually the point that you must then call out the whole namespace multiple times. Or am I missing something that you are pointing out?

Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

[Jani Giannoudis]

var reminds me to VB's Dim and is - from the engineering perspective - a regression. For me it's a good practice to document/describe which type of variable you are working.

Cheers, Jani Giannoudis Meerazo.com - Resource Sharing Made Easy | Co-founder

[Nagy Vilmos]

Use Application Hungarian[^]. The prefix is what the variable is for rather than what it is:

var codeCurrency; // the code for the currency, eg USD
var nameCurrency; // the name for the currency, eg Green Back

Personally, I'd try and get rid of non-explicit declarations where you can and only resort to Apps Hungarian when you have to use vars.

---

Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

[YvesDaoust]

If I were you, I would first wonder how much variable types matter to me. I mean types of any variable in the project. If the types matter so much that you feel like to reflect them explicitly in the names (HN), then something must be done. You have at least three options: 1) use a prefix that indicates an implicitly typed variable (var),

     var \_\_\_Count= 0;

Cheap, and uninformative. 2) use a prefix that indicates the actual type choosen by the compiler.

      var intCount= 0;

Harder but gives an opportunity to improve your mastership of the code. 3) retype the variable to its proper type rather than var (and apply your standard naming policy).

      int intCount= 0;

Strongest and slightly more risky (deeper refactoring). On the opposite, if you use no naming convention for the ordinary variables, why should you care more about vars ? If your concern is to improve readability without refactoring, just comment.

      int Count= 0;
      /\*int\*/ var Sum= 0;

[Steve Crane]

I don't agree that using var is always lazy. It can have a place in making code more readable when declaring types with really long names. For example

SomeClassWithAReallyReallyLongName whatever = new SomeClassWithAReallyReallyLongName();

is (to me) less readable than

var whatever = new SomeClassWithAReallyReallyLongName();

The rule I follow is to use var wherever possible, but only if the declaration explicitly indicates what type the var will be. For example

var start = new DateTime();

or

var start = DateTime.UtcNow;

are acceptable while

var data = GetData();

is not, and should rather have the type explicitly declared.

[jim lahey]

the thing that tells me that it's an implicitly typed local variable is the keyword var. I've got a VS extension (can't remember which one, sorry) that tells me the exact type when I hover over it with the mouse. As for naming conventions, I'm of the opinion that the name should semantically express the usage, so this would be totally fine with me:

var count = 0;

I can tell from the name what it's there for and by the assignment I can tell it's an int. I understand that some people might get confused by this:

var count = someObject.GetCount();

But all the above example means is that the above *might* be a short or long, and you can mouseover the method call in the assignment if you're desperate to know the exact type you're assigning. It's a whole number of some sort. If you're assigning anything other than int, short or long from a method called GetCount(), your method naming is wrong. Using a single byte to return a count is a bit of a special case which is why I haven't mentioned it. I've also never encountered a need to do so, incidentally. For some reason I get quite annoyed when people claim using var is bad practice because it introduces bugs to the code or don't get the fact that it's not the same as dynamic typing because they think it's the same as JavaScript. var works just fine, it means I don't repeat myself all over the place and is statically typed which means it won't even compile if I've done something wrong.

[Robert Neaves]

Yes, that makes you a dick.

[dave dolan]

Absolutely agree. I 'var' like a champ and my life is easier for it. The only thing that annoys me is when I run into legacy API's that return non-generic IEnumerable and you can't use it in the foreach loops! It almost makes me want to convert them to a for loop just for spite. Ok, not really on that last part.