Re: passing via instance variable or regular ()

On Fri, May 11, 2012 at 9:20 AM, sam jam <[e-mail]> wrote:
> Using @ does have advantages as well though. Using () to pass variables
> internally within the class leads to less readable code I think. For one
> you need to pass variables down the chain even if you are not using them
> at each point down the chain. That makes for very ugly code versus using
> @ to leap frog methods.

First of all that code is _explicit_ - that's not necessarily "ugly".
Using instance variables to avoid having to pass arguments to method
calls has another disadvantage apart from the ones I mentioned
earlier: it is not obvious what's happening here because information
is not passed explicitly.  If you notice you have to pass too many
variables down a call chain then this is an indication that you have
not chosen proper abstractions of your state.  Could be that all these
variables can go into a single class (even if it's just a one liner
Struct) and then you only need to pass an instance of this class.
Benefit of this is that you get another entity which you can attach
documentation to and it can be given a telling name.  By passing state
"behind the scenes" readers of the code will have a harder time to
understand what's going on and the code is less modular because for a
method there exists an additional precondition (i.e. that some
instance variables are set in a particular way).  By using unobvious
ways to pass state you gain a bit laziness at the time of writing but
pay with increased effort during reading and understanding later.
This is especially important for maintenance.  Compilers can deal with
arbitrary convoluted code, but it must be readable in order to be
maintainable.

> I could call last from some other class or method. But in some cases I
> see no advantage here. Sometimes when I make classes they are for very
> specific tasks,

_All_ classes should be for very specific tasks!  That's the whole
point of software engineering: you have a certain amount of
functionality that must be delivered by a program and it is our task
to distribute that functionality across program artifacts (methods,
classes, modules) in a way that the result fulfills some requirements

 - desired functionality must be guaranteed
 - a certain level of performance must be achieved
 - maintainability, which consists of
   - readability
   - modularity
   - test coverage

Not necessarily with priorities in this order.

> a bunch of methods that make up a larger system. The
> steps for that system always need to be called in order. I suppose if I
> wanted to reuse the steps in other places it would be best to use ().

You would typically start out with a public method which calls private
methods in that defined order.  If you find later that you could use
those private methods on their own you can still make them public.
Basically the rule of thumb here is: make as few things public as
possible and needed for the task and pay special attention to the
interface because that is set in stone (not really but the cost of
changing a public interface is usually extremely high).  It's must
easier to make something private public later than to change a public
interface!

> I also noticed Robert mentioning that he would avoid using the name
> variable as it is only used once. This brings me to a second question.
> Sometimes I find that using variables in this way can improve code
> readability as well. Perhaps I am writing a Feistel cipher and it makes
> sense to name parts @l and @r during the encryption rounds. The
> resulting cipher or plaintext is then @l + @r. I then need to remove the
> padding from the resulting plaintext, so even though I pass @l and @r
> only once to the remove padding method, it makes sense to say
>
> ciphertext = @l + @r
> remove_padding(ciphertext)
>
> or is this needlessly cluttering my code with variables?

It depends.  If you want to document then you can also do things like these:

remove_padding(@l + @r) # ciphertext
remove_padding_from_ciphertext(@l + @r)

> I see a lot of
> times in my code I use an = sign like this, to make it read more
> clearly, but sometimes I also find myself doing it needlessly. How do
> you feel about this?

Your feeling is probably right. :-)

> Also in my code I did this instead
>
> @ciphertext = @l + @r
> remove_padding(@ciphertext)
>
> I find that using instance variables helped me make the following code
> look nicer

Please don't do that.  It comes at a price (see my earlier statements).

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/