The classic Case bug
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
be able to spot these by now...
Baaah, my eyes are tired right now :-O
"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
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
Yup, this one is a real classic ;)
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
And that's why I like (against general popularity) the following notation:
public MyClass(int p_intID, ..., bool p_blnIsUpdate)
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
Have I mentioned that properties are evil?
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
public MyClass
{
public int IsUpdate { get... set...}...
public MyClass(int id, ..., bool isUpdate)
{
_id = id;
...
_isUpdate = IsUpdate;
}
}You'd think by now I'd be able to spot these by now...
cheers, Chris Maunder
CodeProject.com : C++ MVP
That's why I very rarely put capitals in my variable naming... ;P
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
That's why I very rarely put capitals in my variable naming... ;P
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveV. wrote:
That's why I very rarely put capitals in my variable naming...
whatifyouneedareallylongvariablenamethen ;P :)
-
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.