Not programming, but a preference question.
-
To help me understand what is being done, or rather, what is intended to be done. I guess they are poorly named variables to begin with, so that should be corrected first, and since almost every single variable is a var, it's taking quite some time to figure out why some choices were made. I should say that this is on top of some poorly written code that needs major re factoring, so that doesn't help.
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
-
wizardzz wrote:
I guess they are poorly named variables to begin with, so that should be corrected first
I would stop there. Name them correctly such that anyone can figure it out. What does switching var to a concrete type gain you? Did you forget you can mouse over. There is a reason that hungarian notation is not used.
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.
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[^]
-
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. variables, should always make sense. All naming should make sense. Go for it. :)
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012) -
To help me understand what is being done, or rather, what is intended to be done. I guess they are poorly named variables to begin with, so that should be corrected first, and since almost every single variable is a var, it's taking quite some time to figure out why some choices were made. I should say that this is on top of some poorly written code that needs major re factoring, so that doesn't help.
If the variable names are difficult to understand, I'd go ahead and rename them and add comments as long as I can defend my reasoning. When I do that, I try to do two checkins one for refactoring and one for actual functionality changes so it's easier to separate the two.
Curvature of the Mind now with 3D
-
wizardzz wrote:
am I dick for changing variables to make more sense?
no. variables, should always make sense. All naming should make sense. Go for it. :)
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)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.
-
If the variable names are difficult to understand, I'd go ahead and rename them and add comments as long as I can defend my reasoning. When I do that, I try to do two checkins one for refactoring and one for actual functionality changes so it's easier to separate the two.
Curvature of the Mind now with 3D
-
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.
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
-
He is claiming he needs to know its type and does not know it because "var" was used. So he would keep var and add the system type as a prefix (i.e. Hungarian notation)
var iAge = GetAge();
Silly IMO. Why do you need to know the type. IDE is smart enough. It is better to name what it is for or add more meaning.
var ageOfUser = GetusersAge();
var ageSearch= GetAgeToSearchFor();
var ageConstraintMin = GetAgeConstraintMin();
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.
I agree on the importance of good naming, and I'm pretty sure wizardzz does too. I stopped using hungarian notation more than 10 years ago, but I still prefer variables not to be declared using var. I know that the IDE provides great help for determining the type of a variable, but when you have large amounts of code that you have to wade through, I've found that it helps that the variables are fully declared.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
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
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:
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 -
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
