Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Blocks for scope control Date: Sat, 21 Jan 2012 13:25:02 +0100 Lines: 56 Message-ID: <9nvp52Fe8iU1@mid.individual.net> References: <9ni009F82hU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net vrIt8jKNawxvyd7Qryv9XAk907nzKs+NurAX5Xy3OTFsQ2bsE= Cancel-Lock: sha1:ItVG9Ba6mMrLx7YEGNbj6tqEJWI= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11564 On 20.01.2012 02:16, Arved Sandstrom wrote: > On 12-01-16 02:55 AM, Robert Klemme wrote: >> On 15.01.2012 22:49, Arved Sandstrom wrote: > [ SNIP ] > >> Regarding the method refactoring argument: if there is so much code and >> hence so many local variables that you want to use blocks to introduce >> smaller scopes chances are that the logic within that blocks is also >> largely independent from the code around so it is a good candidate for >> refactoring anyway. The reason for refactoring into methods isn't the >> scope but the independent logic. > Let me give you an example. Some days prior to writing my post I had to > write some code that processed a number of items in a similar fashion. > Each item was a matter of 2 or 3 lines of code. In theory each process > could have been collapsed into one very long line with multiple > duplicated and chained method calls, rather than use temporary local > variables, but I abhor this practice. So for clarity I kept the > operations on each item as 2 or 3 lines of code with at least one > temporary local variable. > > Although the type of the local variable was the same, the operations > that produced it were not - they depended on the item. So any method > that would have replaced all these individually simple simple groups of > operations would have been either a moderately complex switch or a > moderately complex if-else if-else structure, less easy to understand, > and more error-prone. Furthermore, a flag would have been necessary to > the method to indicate which branch to take. Why _one_ method? There could be a method for each variant, couldn't it? Chances are that the same code could be used for several items so you end up with less methods than items. > As you may have guessed this logic had to do with post-processing > various String and Boolean command-line options delivered by a > command-line processor. Quite frankly there is nothing pretty about > this, and there never has been in any language I've ever used - all you > can hope for is to keep the code clear, as error-free as possible, as > change-proof as possible (one of the main reasons for me using local > blocks actually), and just tolerate the boilerplate processing otherwise. I agree that this boilerplate is tedious, regardless how you do it. But I didn't guess that your description was about such a scenario. ;-) > However, the intent of the thread was to get some feedback, and I thank > you all for it. You're welcome! Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/