Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Fri, 21 Jun 2013 04:16:32 +0000 (UTC) Organization: A noiseless patient Spider Lines: 81 Message-ID: References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <19wnriq53qxel.u9rt8wy6z52g.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 21 Jun 2013 04:16:32 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="31087"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19J48JiG6Zhooz2eeDXB4KkuV1z4Dup1sQ=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:YfQBn4uHscltubUZqxA31wUCzJw= Xref: csiph.com comp.lang.java.programmer:24494 On Thu, 20 Jun 2013 23:33:56 -0300, Arved Sandstrom wrote: > 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'm with you there. > I'll admit that verbosity does usually add maintainability complexity, > My attitude is that well-laid out code with well-thought out names and intelligently commented offers about the best chance of being more easily maintainable. I prefer blocks of well formatted and carefully written comments places ahead of what they describe to any other type. > if not the other kind. But not always. I've seen plenty of code that is > conceptually quite complex but very terse. > I've certainly see some memorable examples of badly documented and over- clever code in the past. One of my favourite examples of bad documentation was actually quite good code: it was just the commenting style that was naff. This was MC 6800 assembler, and the house style was to add a comment alongside every instruction whether it needed it or not: the machine had INC and DEC instructions to and or subtract 1 from a register, but did it really add anything the write "BUMP THE B REGISTER" alongside every INC B instruction? As it happens, my worst ever example was also assembler: this time PLAN 3 assembler for an ICL 1900. In this case it was a lineprinter page, i.e. about 60 instructions whose task was the work out the date of the last day of the current month so it could be printed on financial statements. it worked by doing arithmetic on the current date in "dd/mm/yy" format This page has two comments: the first said "Calculate the last day of the month" and the second said "Works until Feb 2100". The rest of the page contained a mess of register-to-register operations and relative branches. There wasn't a single label or variable name in the whole mess. I never met anybody who could follow it past its first dozen steps - and that includes me - and I used to be fairly good at programming in PLAN. The silly thing was that the date calculation was trivial on a 1900, which held dates internally as days since 31 Dec 1899 and provided a set of date manipulation subroutines. The obvious solution, given that library, and writing the routine in pseudo-Java in deference to this 'ere august forum, looks like this: public String lastDayOfMonth(String today) { int day = 1; int month = today.substring(3,2); int year = today.substring(6); if (month > 12) { year++; month = 1; } days = gdatebin(String.format("%02d/%02d/%02d",day, month, year)); return gbindate(days - 1); } ... and wasn't much longer in assembler. gdatebin() converted a date string into binary days since 31/12/1899 and gbindate() did the reverse. I have no idea why the bloke thought his mess of assembler would fall over after Feb 2100: the 1900 held dates in a signed 24 bit number, so its Y2K moment isn't due until some time in 24866 AD. And, yes, I do know my algorithm worked correctly despite leap years and all: it ran for years as part of an accounting package and anybody could see exactly how it worked even though it was written in COBOL. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |