Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?= Newsgroups: comp.lang.java.programmer Subject: Re: Java blunders Date: Wed, 23 Jul 2014 22:11:35 -0500 Organization: A noiseless patient Spider Lines: 50 Message-ID: References: <53d0629b$0$291$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 24 Jul 2014 03:11:54 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="8cedddb29338592f734c41b16a68fadc"; logging-data="12703"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mxwCqGpb7ITjnPF0KJctYi7pcawCkY4I=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <53d0629b$0$291$14726298@news.sunsite.dk> Cancel-Lock: sha1:6cJRgr2ZGCzvJun/MBKUlQuSq4I= Xref: csiph.com comp.lang.java.programmer:29255 On 7/23/2014 8:34 PM, Arne Vajhøj wrote: > On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote: >> C. On the balance, I think matching curly braces is superior to >> begin/end-ish constructs. If you're spending too much time trying to >> figure out where you have an extra or a missing curly brace, then, quite >> frankly, your IDE is defective. My IDE points out matching curly braces >> and can even fold them based on appropriate matching, and it has been >> able to do so since before Java was invented. Possibly since before I >> was born, even. > > To me having an IDE make up for something missing in the > language does not excuse that the feature is missing. > > An IDE is just not always present when reading code. > > (and I think the readability is more of a problem than > the fixing one too few or one too many problems) If you're arguing that begin/end is superior for readability... it's not. It's no better, and could potentially be worse. 1. If you have deep nesting, it's almost certainly going to be mostly or all if statements at the bottom. Loops don't nest deep in practice (you could make a loop nest larger than 3 a compiler error and almost all production code would still compile). So distinguishing between all the different kinds of classes of block structures buys you very little, and nothing at all in the worst classes. 2. Close structures are less well-coordinated among different languages. Is it end, endif, end if, or fi? 3. When you do scans of code, you're almost certainly not looking for braces or begin/end-style keywords. You're looking at the indentation level primarily. The signal for a termination of a block, then, is a mostly-empty line that contains the close construct at the appropriate indentation level. end doesn't help you there. 4. The smaller '}' typing hides what is effectively not semantically valuable text, given the preference for indentation level instead. Seeing a word like 'end' means you have to parse it to make sure you can ignore it. This effect is probably very small and may not actually exist. 5. It's less typing. Not a strong argument, but given no strong argument for an end-like construct in the first place (see above), it does help tip the balance if you're undecided. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth