Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?= Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Mon, 17 Jun 2013 17:36:36 -0500 Organization: A noiseless patient Spider Lines: 77 Message-ID: References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 17 Jun 2013 22:31:39 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="95ab4c362dcce54022543f80bbbb46d3"; logging-data="19502"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NTiWm953fmjOsVPifIRRzHTmV1qlKzCk=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Thunderbird/22.0 In-Reply-To: Cancel-Lock: sha1:zRXlbH2dqV9ISGGz4dFMUHPxSRU= Xref: csiph.com comp.lang.java.programmer:24445 On 6/17/2013 8:46 AM, lipska the kat wrote: > ... and what is your opinion of defensive coding? The term, as I understand it, refers to coding under the assumption that everyone who uses your API is a stupid idiot who can't follow your rules properly. The matter at hand here is basically a stylistic concern about which is mentally easier to follow, which falls under the category of "everyone has an opinion which is strongly held and won't be changed." > This discipline is hard to learn and once learned even harder to > un-learn. This is why I don't like things like > > return str.equals("yes"); > > It's lazy coding and harder to understand than my example To you, maybe. To me, no. This kind of one liner immediately indicates to me that the function is equivalent with the notion that the string is exactly "yes". In your example, by contrast, that equivalence is not obvious: it says that the answer is false unless the string is exactly "yes", and uncovering the functional equivalence requires resolving a double-negative. > if(something){ > return something; > } > else if(something else){ > return something else; > } > else{ > return some other value > } > > It is much easier to understand and debug > the following Style wars much? To me, personally, early-return is often valuable, especially in languages like C++ or Java which have useful constructs for handling post-call cleanup such as RAII or try-finally blocks. I'm going to stop short of saying I prefer early-return, since it is very much a decision that applies in a specific context, and these examples are all trying to apply a universally generic rule. An example of my preferred code style would be something like this (the comments preceding most of those blocks of code are necessary in this style--if how you got there isn't trivially obvious, explain what it means to get there): Frabnaz getResourceFromKey(String key) { // Normalize the key so we know exactly how to refer to it in our // caches. key = normalize(key); if (!isValid(key)) throw new IllegalArgumentException(...); // We have a hyper-optimized variant of this if we know this is // already on a local filesystem if (isLocalFile(key)) return getLocalFileResource(key); // This resource must be on the network. To keep this from killing // performance, cache uses... MagicCache cache = foobarToGrabTheCache(); if (cache.hasResource(key)) return cache.getResource(key); // Can't find it in the cache, so download it but save off a copy // in the cache. Frabnaz result = getResourceFromNet(key); cache.putResource(key, result); return result; } -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth