The classic Case bug

Chris Maunder

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

leppie

The compiler error should be the first hint ;P On 2nd thought, I thought those were the new C# 3.0 auto properties, but then I noticed the ... :-O

xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008)

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)