Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe25.iad.POSTED!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: About java program. References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <19wnriq53qxel.u9rt8wy6z52g.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 72 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Sat, 22 Jun 2013 01:39:29 UTC Organization: Public Usenet Newsgroup Access Date: Fri, 21 Jun 2013 22:39:28 -0300 X-Received-Bytes: 4728 Xref: csiph.com comp.lang.java.programmer:24506 On 06/21/2013 11:24 AM, Daniele Futtorovic wrote: > On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: >> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >>> I'm all for defensive programming, but I think that there's a limit >>> where it can be on the verge of silliness, and that that limit has been >>> grazed here. >>> >>> Less-than-bright programmers IMO cannot be a justification for crossing >>> that line; less-than-bright programmers have more ways to mess things up >>> than you could possibly ever guard against. "Do not underestimate the >>> ingenuity of complete fools", as the saying goes. >>> >>> And for me, there is an additional aspect: if a piece of code does >>> something simple, something basic, then I will want it to be short, and >>> vice-versa. Verbosity of code, to me, should hold a first-glance >>> indication of the complexity of the algorithm. In other words: be terse >>> IFF it's basic, be verbose IFF it's not. >>> >>> Perhaps your mileage does vary. No beef with that. Just throwing in my >>> two cents. >>> >> It's a good discussion. I'm not personally convinced that verbosity adds >> complexity, as a rule. There's really two types of complexity here: >> maintainability complexity - as in, can Joe Blow 12 months later >> understand the code best if it's compact versus unrolled, and formal >> complexity, cyclomatic and otherwise. >> >> I'll admit that verbosity does usually add maintainability complexity, >> if not the other kind. But not always. I've seen plenty of code that is >> conceptually quite complex but very terse. > > Sorry to nitpick, but I don't think you understood me right. I'm not > saying that verbosity adds complexity; I'm saying: if the piece of code > does something tricky, something complicated, tend to make it verbose, > otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. > unrolled, step-by-step) code holds the message "here be dragons". (And > if it cannot be made verbose, then it means it absolutely requires an > in-line comment). We're very much in agreement, on all points you just made. > At least the way I perceived it, this discussion was about making stuff > verbose indiscriminately, viz. basic code as well. I disagree with that > in the above sense. > I won't speak for anyone else, the argument I was making was for verbosity in support of defensive programming. I see Java code all the time where exceptions are try-caught with no thought placed into handling the problem somewhere - defensive coding fail...and handling it properly would add verbosity. I see main methods all the time where someone assumes the number and type of arguments. Defensive coding fail. I see methods all the time - like I said - where the same coder wrote the calling code and called code, and makes assumptions about what the calling code will do. Defensive coding fail. Or they make the naive assumption that people read Javadocs thoroughly. It's not the calling code's responsibility to protect the called code, after all. Given that we have to consider the bounds of parameters carefully, I don't see how some verbosity in the form of defensive code is objectionable. "Here be dragons" often means simply that there is - that we have to guard against what the calling code is doing. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift