Spot the bug (three line program) and a question on how to order execution flow in a OOP

[raylopez99]

Spot the bug (hint: case sensitive).

Gave me an infinite loop, and drove me nuts (lost over an hour finding
it). This sort of stuff should IMO be caught by the compiler.

/*
private int ccUsrInputArrLength;
public int CcUsrInputArrLength
{ get { return CcUsrInputArrLength; } }

*/

Now another question: how's the best way to order how your OOP will
execute? I have a bunch of methods, and they have to execute in a
particular order.

Right now, I just comment each method saying "run this method first/
second/third" etc.

Is there a more rigorous way (for code maintenance)?

RL

 

[Tom Dacon]

That's the best argument there is for not having two variables that differ
only in case. That rule -widely ignored - has been considered best practice
since the very earliest days of C - like back in the 80's.

Tom Dacon
Dacon Software Consulting

 

[Tom Dacon]

And on the execution order question:

1. Try do design your objects so that they don't require specific order of
execution for your methods;
2. If you can't or won't do that, make those methods private or protected,
and write a public wrapper method that executes them in the correct order.

Tom Dacon
Dacon Software Consulting

 

[Doug Semler]

Spot the bug (hint: case sensitive).

Gave me an infinite loop, and drove me nuts (lost over an hour finding
it). This sort of stuff should IMO be caught by the compiler.

/*
private int ccUsrInputArrLength;
public int CcUsrInputArrLength
{ get { return CcUsrInputArrLength; } }

*/

This is why I always prefix my private backing stores with a '_', but that's
a personal style preference. You run into this problem when Intellisense
"completes" a property definition when you haven't yet put the backing store
in (but you know what the name is going to be).

Now another question: how's the best way to order how your OOP will
execute? I have a bunch of methods, and they have to execute in a
particular order.

Right now, I just comment each method saying "run this method first/
second/third" etc.

Is there a more rigorous way (for code maintenance)?

(State machines notwithstanding
If you require a specific order of execution, you are not OOP, IMHO. If you
require a specific order of operation, you should think about creating
private methods that do the funcitonality and have one public function that
calls the private methods in the correct order. Remember, in OOP, an object
instance has state. Functions can either transform the current object or
return a new object (while keeping the current object unchanged). (My
personal preference is transformations return a new object). Public
functions on a specific object instance should be able to operate
independently of each other regardless of the current state of the object in
the OOP world.

JMO from experience...

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

 

[Peter Duniho]

Spot the bug (hint: case sensitive).

Gave me an infinite loop, and drove me nuts (lost over an hour finding
it). This sort of stuff should IMO be caught by the compiler.

Then how would you write a recursive property?

Now another question: how's the best way to order how your OOP will
execute? I have a bunch of methods, and they have to execute in a
particular order.

I agree with Tom on both points (basically in both the
only-different-by-case and required-order-of-calling, the answer is
generally "don't do that").

In addition, if you really must have methods that have to execute in a
specific order, you should try to organize your class so that either the
methods that have to execute first are simply done so automatically, or
you should check whatever state it is that the order of execution
creates that you're depending on, and throw an exception if the state is
not appropriate for a method that should be executed after some other
method.

If the state is implicit in some external component, then you should add
some variable to track the state, so that you can detect the
out-of-order case and throw the exception.

Pete

 

[Michael A. Covington]

That's the best argument there is for not having two variables that differ
only in case. That rule -widely ignored - has been considered best
practice since the very earliest days of C - like back in the 80's.

Well said. I would also say not to have two variables that are pronounced
alike. I once encountered Menu2, Menu_2, MenuTwo, and MenuToo, all in the
same program.

 

[Jon Skeet [C# MVP]]

That's the best argument there is for not having two variables that differ
only in case. That rule -widely ignored - has been considered best practice
since the very earliest days of C - like back in the 80's.

There aren't two variables here varying only in case - there's a
variable and a property

Personally I find it a handy convention, and the *one* time I made this
mistake, it took me about 10 seconds to spot it when I got a stack
overflow.

I'm astonished that it took Ray over an hour to find it. A single debug
session should make it blindingly obvious.

 

[Mads Bondo Dydensborg]

Spot the bug (hint: case sensitive).

Gave me an infinite loop, and drove me nuts (lost over an hour finding
it). This sort of stuff should IMO be caught by the compiler.

/*
private int ccUsrInputArrLength;
public int CcUsrInputArrLength
{ get { return CcUsrInputArrLength; } }

*/

You might be interessted in static analysis, such as Smokey:

https://home.comcast.net/~jesse98/public/Smokey/

It has a rule for stuff like that.

I think even FxCop has it. It is quite nice to integrate these tools with
your integrationserver.

Regards,

Mads
--
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo
Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77
34

 

[raylopez99]

I'm astonished that it took Ray over an hour to find it. A single debug
session should make it blindingly obvious.

--

For you maybe Jon, but like I said, I'm learning--and this program is
getting very complex--over a dozen pages of source code and numerous
objects (the stupid C# convention of inline coding doesn't help,
unlike the more organized C++ style). And I can spot a mate in five
rather easily in chess too; you probably can't. Programming and chess
(and programming chess) is like learning a language; practice makes
perfect, and it has almost nothing to do with native intelligence, as
evidenced by Jon and Pete's posts in this NG!

I'll take Tom's advice regarding program flow [with the caveats in
brackets]

1. Try do design your objects so that they don't require specific
order of
execution for your methods;

[in theory, but in practice even with OOP you get "backed into a
corner" and unless you've designed from the very beginning everything
to be modular--which takes a lot of planning and work, I think more
work than not in most cases--it's easier just to do a quick fix like
suggetion 2. below]


2. If you can't or won't do that, make those methods private or
protected,
and write a public wrapper method that executes them in the correct
order.

[this is a good idea; easy to do and a quick fix--perfect for a rapid
coder and hobbiest like me--the only person maintaining this code is
me (and for you professional programmers, that's a form a job
security. They can't outsource you from Bangladore if nobody else can
understand your code, LOL!]

RL

 

[Jon Skeet [C# MVP]]

For you maybe Jon, but like I said, I'm learning--and this program is
getting very complex--over a dozen pages of source code and numerous
objects (the stupid C# convention of inline coding doesn't help,
unlike the more organized C++ style).

The size of the program should be irrelevant. Assuming you can
reproduce the problem, just stepping through the code should have shown
you the property causing the issue very quickly. Once you know which
property is causing the problem, diagnosing the bug is trivial.

 

[Michael S]

I think the real problem is the C# compiler not giving you a warning.

- Michael Starberg

 

[Jon Skeet [C# MVP]]

I think the real problem is the C# compiler not giving you a warning.

It's a tricky one - sometimes, just rarely, a recursive property call
is useful. It would be slightly odd to forbid it (and I view a warning
as effectively forbidding something - I like warning-free code

On the other hand, it *is* a source of errors, albeit a generally easy
one to find and fix.

Anyone know if FxCop spots this?

Jon

 

[Michael S]

It's a tricky one - sometimes, just rarely, a recursive property call
is useful. It would be slightly odd to forbid it (and I view a warning
as effectively forbidding something - I like warning-free code

On the other hand, it *is* a source of errors, albeit a generally easy
one to find and fix.

Anyone know if FxCop spots this?

Jon

Just tested and it and FxCop somewhat catches this.
But the warning is not for using the property inside the property,
but for the private field never being used. Enough for me.

But I never makes this error in C#.
I make properties bu starting with a private field
and then go Refactor -> Encapsulate Field.

Also, why I also use the private field camelStyle, public propery
PascalStyle,
as Visual Studio 2005 refactor tool suggests that this notation should be
used.

Also, if I need a recursive property, I'd code the recursion in a method
and call that method in the getter. I think it is a bad thing to call a
property
iniside a property just because it may be mistaken for a bug.

- Michael Starberg

 

[Tom Dacon]

There aren't two variables here varying only in case - there's a
variable and a property

I thought about using other terminology such as "symbol", but I figured that
the informality would not bring out the inner nit-picker in too many people.

My point, however, remains valid in spite of my imprecision of expression.

I do agree that it shouldn't have taken more than a few seconds to figure
out what was going on.

Tom Dacon
Dacon Software Consulting

 

[Tom Dacon]

It's a tricky one - sometimes, just rarely, a recursive property call
is useful. It would be slightly odd to forbid it (and I view a warning
as effectively forbidding something - I like warning-free code

On the other hand, it *is* a source of errors, albeit a generally easy
one to find and fix.

Anyone know if FxCop spots this?

Jon

I have one such recursive property setting in one of my classes, and it's
there for what I think is a good reason so I'm not motivated to code around
the recursion.

FxCop DOES spot this, and in this one case only I turn off the FxCop warning
so that my compile will be clean. Unfortunately there's no way to turn it
off for just the one property setter method, so I'm giving myself wider
exposure to the problem in that project. Oh well, life is full of
compromises.

Tom Dacon
Dacon Software Consulting

 

[Jon Skeet [C# MVP]]

I thought about using other terminology such as "symbol", but I figured that
the informality would not bring out the inner nit-picker in too many people.

Nah, just me

(The appropriate terminology would be "member" though.)

My point, however, remains valid in spite of my imprecision of expression.

Well, sort of - but by following conventions, I've never found it a
problem. Now, if someone names things haphazardly, i.e. sometimes uses
VariableName, sometimes uses propertyName, sometimes uses variableName
and sometimes uses PropertyName then it's more of an issue, because
it's not immediately obvious what's being used. In this case it's
pretty clear IMO.

It's the kind of convention that I'll stop using if I ever have a
significant problem with it - but it's cost me so little time so far
that I don't think it's an issue

 

[Tom Dacon]

Nah, just me

(The appropriate terminology would be "member" though.)

Well, not exactly. The point applies to everything in scope, including
argument names and local variables as well as fields, properties, and method
names. And anything else that I forgot to mention.

Well, sort of - but by following conventions, I've never found it a
problem. Now, if someone names things haphazardly, i.e. sometimes uses
VariableName, sometimes uses propertyName, sometimes uses variableName
and sometimes uses PropertyName then it's more of an issue, because
it's not immediately obvious what's being used. In this case it's
pretty clear IMO.

It's the kind of convention that I'll stop using if I ever have a
significant problem with it - but it's cost me so little time so far
that I don't think it's an issue

I know what you mean. I have many personal coding guidelines and standards
that I've developed over many years and many millions of keystrokes, and I
follow them with varying degrees of conviction. Every time the paradigm
shifts, I sit back and look at them to see if I still believe them enough to
continue with them, or whether things have changed enough around me to try
out someone else's notions about what's good. Some things I abandon, some
things I modify in the light of current usage if it looks like a good idea,
some I hang onto because they still look worthwhile to me.

I'll tell you one thing - I'm glad to see the last of Hungarian notation. I
never could buy into that, at least the way that the MS programmers
distorted Simonyi's original intent.

Tom

 

[Jon Skeet [C# MVP]]

Well, not exactly. The point applies to everything in scope, including
argument names and local variables as well as fields, properties, and method
names. And anything else that I forgot to mention.

Ah, good catch. Member would have coped with this situation but not
others

I know what you mean. I have many personal coding guidelines and standards
that I've developed over many years and many millions of keystrokes, and I
follow them with varying degrees of conviction. Every time the paradigm
shifts, I sit back and look at them to see if I still believe them enough to
continue with them, or whether things have changed enough around me to try
out someone else's notions about what's good. Some things I abandon, some
things I modify in the light of current usage if it looks like a good idea,
some I hang onto because they still look worthwhile to me.

Right. One thing I *do* find important is to follow the "public"
conventions of a platform when it comes to naming - making methods and
properties Pascal-cases in .NET for instance. When people bring
conventions from one platform to another, chances are they're still
thinking in the idioms of the old platform too.

(I have a couple of exceptions to that - in Java, these days I use the
..NET conventions for interfaces and constants, because it makes things
definitely more readable IMO. It still makes me feel uneasy though.)

I'll tell you one thing - I'm glad to see the last of Hungarian notation. I
never could buy into that, at least the way that the MS programmers
distorted Simonyi's original intent.

I'm not a fan of Hungarian notation of either kind, but I know that
Peter likes the "proper" form (as opposed to the MS form).

 

[Peter Duniho]

[...]
I'm not a fan of Hungarian notation of either kind, but I know that
Peter likes the "proper" form (as opposed to the MS form).

Heh heh...I was wondering if that would come up.

To be fair to some at Microsoft, "the MS form" refers mainly to the
"systems" Hungarian, especially as it's seen in public (the entire Win32
API, for example ). It is indeed an abomination (having all of the
disadvantages of Hungarian, but practically none of the advantages), but
it is not the only form of Hungarian used there.

The "proper" form of Hungarian is in fact used by some at Microsoft,
especially those groups who can trace their ancestry back to the
original "Applications Division" (by either product lineage or staffing
lineage).

And yes, I admit it. I like and use the "proper" form of Hungarian,
especially in my own code (as opposed to when fixing someone else's).
Even when I'm writing .NET code, all of the non-public parts of my
classes use Hungarian notation. So sue me.

Pete

 

[raylopez99]

THanks to all that replied; I learned a few things (the Refractor tool
stuff was pretty cool--I still haven't figured out what the refractor
button is for in VS2005 though).

Pete and Jon--I'm just riling you about native intelligence--thanks
for your help.

RL

On Sep 24, 4:42 pm, raylopez99 <[email protected]> wrote: