Not programming, but a preference question.
-
wizardzz wrote:
since almost every single variable is a var, it's taking quite some time to figure out why some choices were made
That is my main dislike of var - when you are trying to read the code, you have no idea what a variable is, or what you can do with it, without looking at some other bit of code and coming back. Explicit variable typing lets you know immediately what type it is and hence what you can do with it. Besides, it's lazy. "I don't want to think about this variable, it just want to get on with the interesting stuff".
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
Besides, it's lazy. "I don't want to think about this variable, it just want to get on with the interesting stuff".
I didn't realize this would be such a hot topic, but yes, I have noticed in some previous projects that this was the case.
-
I think we had a misunderstanding regarding your first response. I didn't mean Hungarian Notation in the strict sense. I meant as a "style" type. I debated using HN in my first post even. See my response to Steve here: http://www.codeproject.com/Lounge.aspx?msg=4281501#xx4281501xx[^]
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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
-
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
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 -
If you are in the pacifier business, you might consider:
var varBinks = getBinkyCount();
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.
-
Dang, maybe I should have clarified. I meant Hungarian Notation "style", not strictly varName, etc. Example:
var BeginDate = item.GetType().GetProperty("BeginDate");
var Locations = item.GetType().GetProperty("Locations");I would prefer to be
var propBeginDate = item.GetType().GetProperty("BeginDate");
var propLocations = item.GetType().GetProperty("Locations");or something like that. This is more of an example of what I meant. I guess I should have initially said, am I dick for changing variables to make more sense?
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.
-
I use Refactor! Pro[^]. Right click on the offending var declared varable and choose 'Make explicit' and there I have a decently declared varable. I'm pretty sure other refactoring tools have a similar feature.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
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.
-
IT doesn't make you a dick.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
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.
-
wizardzz wrote:
So does it make me a dick to want to use some sort of Hungarian Notation on these vars?
Maybe. Depends. A var should only be used where the type can be easily ascertained from the context and the variable's name should indicate what it is.
var veggie = new Cucumber(); // yep, ok
var dingdong = SomeFunctionOfObtuseNaming(); // nope, not ok
var custList = GetCustomerList(); // Yep, OK
Sometimes var is required by the language when using LINQ.
var custList = from CustomerList select Name, Address where AccountValue > 1000; // dubious syntax, but you get the drift I am sure
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 Braunahmed 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
-
I do not see why people get hung up on var. (I am quite certain I will ge downvoted for this post) IMO it is cleaner.
namespace ThirdPartynamespace
{
class RequiredComponent
{
}
}...
namespace DifferentThirdPartyNamespace
{
class RequiredComponent
{
}
}namespace Local
{
class Thingamajig
{
var component = new ThirdPartyNameSpace.RequiredComponent();
var diffComponent = new DifferentThirdPartyNameSpace.RequiredComponent();
//vsThirdPartyNameSpace.RequiredComponent ewComponent = new ThirdPartyNameSpace.RequiredComponent(); DifferentThirdPartyNameSpace.RequiredComponent ewDiffComponent = new DifferentThirdPartyNameSpace.RequiredComponent();
}
}Ok, so now you will say that is a rare case. Maybe it is but because this case happens (actually it happens to me alot but mostly because how I use namespaces), you should follow patterns being set. You may not be always worried about thread mishaps but you still program for it. Other reasons: Return object changes.
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.
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
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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.
-
I do not see why people get hung up on var. (I am quite certain I will ge downvoted for this post) IMO it is cleaner.
namespace ThirdPartynamespace
{
class RequiredComponent
{
}
}...
namespace DifferentThirdPartyNamespace
{
class RequiredComponent
{
}
}namespace Local
{
class Thingamajig
{
var component = new ThirdPartyNameSpace.RequiredComponent();
var diffComponent = new DifferentThirdPartyNameSpace.RequiredComponent();
//vsThirdPartyNameSpace.RequiredComponent ewComponent = new ThirdPartyNameSpace.RequiredComponent(); DifferentThirdPartyNameSpace.RequiredComponent ewDiffComponent = new DifferentThirdPartyNameSpace.RequiredComponent();
}
}Ok, so now you will say that is a rare case. Maybe it is but because this case happens (actually it happens to me alot but mostly because how I use namespaces), you should follow patterns being set. You may not be always worried about thread mishaps but you still program for it. Other reasons: Return object changes.
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.
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.
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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
-
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
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.
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
var
reminds me to VB'sDim
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
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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 BackPersonally, 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
-
var
A big ugly word. I don't use them unless I really need to. Now I have a project to add to that another developer created. Cool. There are a lot of vars in here. Unavoidable, too. Now, I'm the head "developer" on this team, and basically have to know all code inside and out pretty darm well. So does it make me a dick to want to use some sort of Hungarian Notation* on these vars? [Editing for clarity] I do not mean adding var to the front, or necessarily the type (though that will be useful in some cases, that's why I mistakenly said HN) I meant using a short form abbreviation to signify what the hell the variable is for rather than just "Loc" "Cust" etc when there are many similar variables.
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
var
s ? If your concern is to improve readability without refactoring, just comment.int Count= 0; /\*int\*/ var Sum= 0;
-
wizardzz wrote:
since almost every single variable is a var, it's taking quite some time to figure out why some choices were made
That is my main dislike of var - when you are trying to read the code, you have no idea what a variable is, or what you can do with it, without looking at some other bit of code and coming back. Explicit variable typing lets you know immediately what type it is and hence what you can do with it. Besides, it's lazy. "I don't want to think about this variable, it just want to get on with the interesting stuff".
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
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.
-
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
var
s ? If your concern is to improve readability without refactoring, just comment.int Count= 0; /\*int\*/ var Sum= 0;
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.