Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Mon, 17 Jun 2013 18:30:20 -0400 Organization: A noiseless patient Spider Lines: 85 Message-ID: References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <19wnriq53qxel.u9rt8wy6z52g.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 17 Jun 2013 22:25:21 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="17683"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+rVMzSb+Xmcvf7wLlo+04z" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 In-Reply-To: Cancel-Lock: sha1:g2B39Kk2D7WFPtbD7RmmXoD7L70= Xref: csiph.com comp.lang.java.programmer:24444 On 6/17/2013 5:38 PM, Arved Sandstrom wrote: > On 06/17/2013 03:49 PM, Eric Sosman wrote: >> On 6/17/2013 2:32 PM, Joerg Meier wrote: >>> [...] >>> Personally, I found your example considerably harder to read than the >>> one >>> liner, as well as harder to read than what would have been my solution: >>> >>> private boolean askYesNoquestion (String str){ >>> if(str.equals("yes")) >>> return true; >>> >>> return false; >>> } >> >> Or, for even greater clarity: >> >> private boolean askYesNoquestion(String str) { >> boolean yes; >> boolean no; >> if (str != null && str.equals("yes")) { >> yes = true; >> no = false; >> } else if (str != null && str.equals("no")) { >> no = true; >> yes = false; >> } else { >> yes = no = false; >> } >> return (no != true && yes != false) == true; >> } >> >> (If we put our minds to it, I bet we can turn the one-liner >> into an entire class hierarchy with runtime-selected plug-in >> provider implementations!) >> > We can joke about it, but the one-liner has problems, especially if not > wrapped in a method like Robert did. I've seen exactly that one-liner > cause dozens of defects over the past 15 years of me doing Java. Not all > programmers out there are superstars like all of us here in CLJP, in > fact 99 percent aren't. If they - not graced with our wisdom and keen > skills and perspicacity - decide to use that short form - they will > almost *never* wrap it in a method that constrains the type being > compared to, or does a null check if that's also unacceptable. In which > case sooner or later - sooner usually - lack of controls elsewhere in > the code, which is par for the course, will make that elegant little > snippet fail. "As simple as possible, no simpler." The observation that a simple construct can be misused -- a true observation -- does not mean that the cure is to add complexity. For one thing, the added bulk offers more opportunities for misuse. static int sum(int a, int b) { return a + b; } static int sum(int a, int b) { int total = a; total += b; return total; } static int sum(int a, int b) { assert Integer.MIN_VALUE <= a && a <= Integer.MAX_VALUE; assert Integer.MAX_VALUE >= b && b >= Integer.MAX_VALUE; Random rand = new Random(); int total; do { total = rand.nextInt(); } while (total - a != b); return total; } Seriously, there are very few reasons to add complexity, and many to reduce it. Complexity can (sometimes) make a needed performance improvement; complexity can (occasionally) provide a self-check or a debugging hook; complexity can (almost never) add clarity. (Truthfully, now: Did you spot the error above on first glance?) -- Eric Sosman esosman@comcast-dot-net.invalid