From: Robert Klemme Date: 2012-05-11T17:33:05+09:00 Subject: Re: passing via instance variable or regular () On Fri, May 11, 2012 at 9:20 AM, sam jam 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/