The classic Case bug
-
Have I mentioned that properties are evil?
-
V. wrote:
That's why I very rarely put capitals in my variable naming...
whatifyouneedareallylongvariablenamethen ;P :)
what_if_you_need_a_really_long_variable_name_then or wiynarlvnt fact is it always worked for me ;-)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
My thoughts, too.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
If you invoke a function call with a syntax for accessing a variable, sooner or later you will invoke a function when you really wanted to access a variable.
-
If you invoke a function call with a syntax for accessing a variable, sooner or later you will invoke a function when you really wanted to access a variable.
I find that a terrible justification. Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
I find that a terrible justification. Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.
I don't write public variables (except for POD types). What I am arguing here is that the function syntax is much better for something that is really a function. Ie, I find much easier to understand this:
dialog.SetFont(font);
than:
dialog.Font = font; // looks like accessing a public variable, when it is really a function call
Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow :rolleyes:
-
Chris Maunder wrote:
Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.
I don't write public variables (except for POD types). What I am arguing here is that the function syntax is much better for something that is really a function. Ie, I find much easier to understand this:
dialog.SetFont(font);
than:
dialog.Font = font; // looks like accessing a public variable, when it is really a function call
Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow :rolleyes:
Nemanja Trifunovic wrote:
Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow
Maybe different naming convention is better solution then avoidance of properties. With the significant code base it's not possible to change it, but then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
-
Nemanja Trifunovic wrote:
Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow
Maybe different naming convention is better solution then avoidance of properties. With the significant code base it's not possible to change it, but then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
Mladen Jankovic wrote:
then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.
Sure. All I am saying is that properties are "too much abstraction" and easily add confusion. If something is a function, it should be invoked as a function, IMHO. Uzgred, cestitam na proslomesecnom clanku :)
-
Chris Maunder wrote:
Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.
I don't write public variables (except for POD types). What I am arguing here is that the function syntax is much better for something that is really a function. Ie, I find much easier to understand this:
dialog.SetFont(font);
than:
dialog.Font = font; // looks like accessing a public variable, when it is really a function call
Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow :rolleyes:
Because coding doesn't end after a single SetFont statement. First, because I have to do that thousand times over and over, until a project is done. Because in a lengthy expression, every additional set of parantheses hurts readability.
q = v.Mag*complex(cos(v.Phase),-sin(v.Phase))/c.Refis closer to the problem domain description thanSetQ(v.GetMag()*complex(cos(v.GetPhase(),-sin(v.Phase())/c.GetRef())(I assume you agree that being close to the problem domain is a good thing)We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Mladen Jankovic wrote:
then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.
Sure. All I am saying is that properties are "too much abstraction" and easily add confusion. If something is a function, it should be invoked as a function, IMHO. Uzgred, cestitam na proslomesecnom clanku :)
Nemanja Trifunovic wrote:
Uzgred, cestitam na proslomesecnom clanku
Hvala! :beer:
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
-
Because coding doesn't end after a single SetFont statement. First, because I have to do that thousand times over and over, until a project is done. Because in a lengthy expression, every additional set of parantheses hurts readability.
q = v.Mag*complex(cos(v.Phase),-sin(v.Phase))/c.Refis closer to the problem domain description thanSetQ(v.GetMag()*complex(cos(v.GetPhase(),-sin(v.Phase())/c.GetRef())(I assume you agree that being close to the problem domain is a good thing)We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistpeterchen wrote:
I assume you agree that being close to the problem domain is a good thing
I agree. However, I am not sure I agree that additional parenthses move you away from the problem domain. In fact, your example just illustrates well what I mean by "too much abstraction".
v.Phasedoes not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties. -
peterchen wrote:
I assume you agree that being close to the problem domain is a good thing
I agree. However, I am not sure I agree that additional parenthses move you away from the problem domain. In fact, your example just illustrates well what I mean by "too much abstraction".
v.Phasedoes not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties.I see your point. A
LinkedList.Sizethat runs through the entire list to count them would be wrong. A property should be a property only if it runs in linear time and has none or "obvious" side effects (e.g. changing rect.width would obviously have the side effect of changing rect.right). I'd even make some room here for dependent values that need to be cached due to long calculation: it should run in linear time most of the time. But I agree that this is debatable. Less technically, it should be only a property if it acts like a property. As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable.
btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post? :cool:
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
I see your point. A
LinkedList.Sizethat runs through the entire list to count them would be wrong. A property should be a property only if it runs in linear time and has none or "obvious" side effects (e.g. changing rect.width would obviously have the side effect of changing rect.right). I'd even make some room here for dependent values that need to be cached due to long calculation: it should run in linear time most of the time. But I agree that this is debatable. Less technically, it should be only a property if it acts like a property. As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable.
btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post? :cool:
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistpeterchen wrote:
As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable
I don't find C syntax very good for math-heavy work, and overuse of parantheses is one of the main reasons for that. Even good ol' Fortran is better. In fact, C syntax sucks in general - why do all these "new" and "clean" languages keep it when they don't aim for the source-level compatibility with C?
peterchen wrote:
btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post?
Not until you mentioned it :)
-
peterchen wrote:
I assume you agree that being close to the problem domain is a good thing
I agree. However, I am not sure I agree that additional parenthses move you away from the problem domain. In fact, your example just illustrates well what I mean by "too much abstraction".
v.Phasedoes not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties.In fact, your example just illustrates well what I mean by "too much abstraction". v.Phase does not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties. Although languages don't enforce any requirement that the use of 'read' properties be limited to values that can be computed in constant (not linear!) time, nor any requirement that the value written to a property have any relation to what may be later read back, that doesn't mean that people shouldn't follow such rules when using properties. I will say that a fair number of classes in .net abuse properties IMHO. For example, I would consider StringBuilder.Length to be a fine read-only property. I do not believe it should be writable. Changing the length of a string should require a method, since doing so has a side effect of affecting the contents. BTW, I wish there were a syntax in vb.net for two very common property templates. Something like:
Friend Property Foo As Integer Using(_Foo)
Refresh
End Propertyas shortcut for
Friend Property Foo As Integer
Get
Return _Foo
End Get
Set(value as Integer)
_Foo = value
Refresh
End Set
End PropertyI would guess that the majority of all properties have get and set routines that do nothing except return or set a field, and a majority of the rest have a get routine that returns a field and a set routine that sets a field and then performs an update. It shouldn't be necessary for the most common case to take eight lines of code.
-
what_if_you_need_a_really_long_variable_name_then or wiynarlvnt fact is it always worked for me ;-)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
Glad I don't have to maintain your code!
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
Yeah, I sure wouldn't want to either. Maybe for a considerable hourly rate most would not be willing to pay :-\
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Glad I don't have to maintain your code!
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
You would be more surprised at my clarity then you would think ;-).
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
In fact, your example just illustrates well what I mean by "too much abstraction". v.Phase does not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties. Although languages don't enforce any requirement that the use of 'read' properties be limited to values that can be computed in constant (not linear!) time, nor any requirement that the value written to a property have any relation to what may be later read back, that doesn't mean that people shouldn't follow such rules when using properties. I will say that a fair number of classes in .net abuse properties IMHO. For example, I would consider StringBuilder.Length to be a fine read-only property. I do not believe it should be writable. Changing the length of a string should require a method, since doing so has a side effect of affecting the contents. BTW, I wish there were a syntax in vb.net for two very common property templates. Something like:
Friend Property Foo As Integer Using(_Foo)
Refresh
End Propertyas shortcut for
Friend Property Foo As Integer
Get
Return _Foo
End Get
Set(value as Integer)
_Foo = value
Refresh
End Set
End PropertyI would guess that the majority of all properties have get and set routines that do nothing except return or set a field, and a majority of the rest have a get routine that returns a field and a set routine that sets a field and then performs an update. It shouldn't be necessary for the most common case to take eight lines of code.
supercat9 wrote:
(not linear!)
Whoops! that's what I meant :-O
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
peterchen wrote:
As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable
I don't find C syntax very good for math-heavy work, and overuse of parantheses is one of the main reasons for that. Even good ol' Fortran is better. In fact, C syntax sucks in general - why do all these "new" and "clean" languages keep it when they don't aim for the source-level compatibility with C?
peterchen wrote:
btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post?
Not until you mentioned it :)
Nemanja Trifunovic wrote:
In fact, C syntax sucks in general - why do all these "new" and "clean" languages keep it when they don't aim for the source-level compatibility with C?
You'd be surprised how important familiarity can be.