Not programming, but a preference question.
-
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:
propBeginDate
why "prop"? The "type" or "what it is" is already part of the name. BeginDate
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 -
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.
The only 'Hungarian' notation you need is clear naming of your variables.
var iAgedoes NOT make your code more readable (it does invite for jokes though, like "the new Apple product" or "a coming IceAge").var cListdoes NOT make your code more readable.var sName... You get the picture. Hoovering over thevarword reveals the type of the variable and is in many cases easier than some weird notation (at least weird in a .NET context). Besides, when isvarREALLY necessary? When working withanonymous types. And how are you sensibly going to 'Hungarian notate' those? :)Varisn't really big and ugly either. At least not always. Consider the following:// I've had code that looked something like the following:
foreach (KeyValuePair>> pair in someDictionary) {
// or...
foreach (var pair in someDictionary) {Which is bigger and uglier? :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
wizardzz wrote:
propBeginDate
why "prop"? The "type" or "what it is" is already part of the name. BeginDate
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 -
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
I love Refactor, but hate Coderush.
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
-
I guess I took my frustration with vaguely named vars out on var itself. I don't necessarily hate them, I see why they are used and necessary. I know I can look like a dick for asking them not to be used. However I should be frustrated at the right thing for the right reason. There is literally a declaration that looks like
var loc = ...
when it's being used as:
Locations.Location loc = ....
Neither of these are nice. I should clarify, there are about 4 different variables referring to different types of locations. Each named very similar/just abbreviated.
wizardzz wrote:
There is literally a declaration that looks like
var loc = ...
when it's being used as:
Locations.Location loc = ....
wizardzz wrote:
there are about 4 different variables referring to different types of locations
yeah, that is pretty bad. Rename away with the knowledge that he who wrote it originally was the d1ck.
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.
-
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 love Refactor, but hate Coderush.
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:
Coderush
Yes, it can be annoying at times ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
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 Braun -
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
