Looking for feedback on coding style

[Dgates]

I'm learning ASP.NET, C# and VB.NET, and hoping to get some feedback
from more experienced programmers on a few issues regarding efficient,
readable, well-organized code.

I'm trying to program anything I do in the best possible "style," even
if it's just a silly experiment (e.g., a simulation to find out the
average number of times you have to roll a die before all six sides
have come up).

With quickie experiments at home, alone, it's hard to ask myself
questions like:

- "Will my co-workers want access to my UnrolledSidesEx ist()
function?"

- "Do I need to speed up the efficiency of this process?"
I'll describe the 2 classes I've coded and then list my 4 main
issues/questions.
---------------------------------
CLASS #1:

The CoinGame class calculates expected results if you play a game
where you can triple your money every time you roll heads (and lose it
all as soon as you roll tails).

For this class, I put all the code into *one big method*, which ended
up nested in about 3 or 4 levels of for-next loops.
---------------------------------
CLASS #2:

The Roller class simulates rolling a die until all sides have come up
at least once. I split this into these methods:

- RunTests()
- RollMultipleTim es()
- UnrolledSidesEx ist()
---------------------------------

ISSUES/QUESTIONS:
(1) I feel "guilty" creating an object. I keep thinking I'd be
"wasting" the computer's time creating an object just for some little
thing, especially when the object would have to be instantiated
thousands of times.

For example:

- a Person object that rolls a die until he's rolled all sides, or
- a Die object that knows which of its sides have been rolled.
----------

(2) I coded all my methods as "static." I never instantiate a Roller
object or a CoinGame object.

Am I defeating the whole point of using an OO language here?
----------

(3) I read a coding practice that said something like:

"Once your [blank] gets to be more than 30 lines long, you should
break it into [blank]s."

Was that referring to breaking a method into smaller methods? And is
the goal simply more readable code?
----------

(4) When I split a method into several smaller methods, I saw a new
dilemma:

Should I pass the same two or three parameters around every time one
method calls another? Or should I declare (private) class-level
variables to which all of the methods have access?
----------
I'm open to any suggestions, whether they're about the 4 issues I
listed, or my basic assumptions, or just a request to see the code in
question.
Thanks in advance.

[Bob Grommes]

"Dgates" <dg****@spamlin kline.com> wrote in message
news:sd******** *************** *********@4ax.c om...

(1) I feel "guilty" creating an object. I keep thinking I'd be
"wasting" the computer's time creating an object just for some little
thing, especially when the object would have to be instantiated
thousands of times.

For example:

- a Person object that rolls a die until he's rolled all sides, or
- a Die object that knows which of its sides have been rolled.
You are overly obsessed with performance. Do what makes logical sense, and
then IF you see a demonstrable performance issue, you can tune from there.
And you will quickly learn what is expensive and what is not. You learn by
doing. Don't be afraid to make mistakes -- be willing to make them.

Objects are your friends ... they are not to be hoarded and used when
absolutely necessary, but used intelligently just like variables or anything
your'e already familiar with. A design with thousands of live objects is
common in any non-trivial application.
(2) I coded all my methods as "static." I never instantiate a Roller
object or a CoinGame object.

Am I defeating the whole point of using an OO language here?
Static is appropriate where the method does not need instance data to do its
work, or where you will share data amongst all instances of a class.
(3) I read a coding practice that said something like:

"Once your [blank] gets to be more than 30 lines long, you should
break it into [blank]s."

Was that referring to breaking a method into smaller methods? And is
the goal simply more readable code?
Yes, you probably were reading that long methods should be broken down into
smaller methods. That is almost always good advice. And yes, the primary
goal is more readable / maintainable code. Remember that you (and perhaps
other humans) will have to read the code; and you can only keep a finite
amount of the problem in your head at one time.
(4) When I split a method into several smaller methods, I saw a new
dilemma:

Should I pass the same two or three parameters around every time one
method calls another? Or should I declare (private) class-level
variables to which all of the methods have access?

Depends on the context. Parameters increase calling overhead, as well as
complexity. So, keeping them to a minimum (within reason) is a Good Thing.

If you find yourself passing the same bits of info around between methods
then they are probably better made into private or protected members. Ask
yourself if the info is an attribute of the class, or something internal to
the method. If it has to do with the class, then it should be a class
member.

--Bob