The classic Case bug

Paul Conrad

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

Optimus Chaos

Yup, this one is a real classic ;)

KarstenK

What says the compiler/linker to this? :confused: ...maybe it is a feature... :-O

Greetings from Germany

Jan C de Graaf

And that's why I like (against general popularity) the following notation:

public MyClass(int p_intID, ..., bool p_blnIsUpdate)

Nemanja Trifunovic

Have I mentioned that properties are evil?

Programming Blog utf8-cpp

J a a n s

Stack overflow exception :confused: I need to increase the ram...;P

*jaans

V 0

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

ChandraRam

V. wrote:

That's why I very rarely put capitals in my variable naming...

whatifyouneedareallylongvariablenamethen ;P :)

Chris Maunder

:confused:

cheers, Chris Maunder

CodeProject.com : C++ MVP

V 0

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

Paul Conrad

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

Nemanja Trifunovic

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.

Programming Blog utf8-cpp

Chris Maunder

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

Nemanja Trifunovic

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:

Programming Blog utf8-cpp

Mladen Jankovic

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

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 :)

Programming Blog utf8-cpp

peterchen

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.Ref is closer to the problem domain description than SetQ(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

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)

Nemanja Trifunovic

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.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.

Programming Blog utf8-cpp

peterchen

I see your point. A LinkedList.Size that 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