Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: please coin a term for a lower order bug Date: Wed, 11 Jan 2012 13:38:18 -0700 Organization: reply hazy, try again Lines: 41 Message-ID: <2p7h0yq8jp.fsf@shell.xmission.com> References: <2pboqbqz49.fsf@shell.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="PnllQd880uOddfy6hsxHuQ"; logging-data="29252"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XMFPG0FS2FJ08uiT6mis5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:9f+SX6L9bBLi8R2sdanCtMNQjHo= sha1:UDEIg/3lLv1COW1lS/iTta7TeJg= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11243 Gene Wirchenko writes: > On Tue, 10 Jan 2012 18:08:15 -0800, Lew wrote: > >>markspace wrote: >>> Jim Janney wrote: >>>> Roedy Green writes: >>>>> What would you call a flaw in a program that had no effect on the >>>>> results, but needlessly made the program slower or confusing? >> >>Slower _is_ an effect on results. >> >>>> What about one that makes it more confusing and needlessly faster? >>> >>> "Needlessly faster" as in the customer didn't need a speed improvement in that >>> feature? I'd say that's Gold Plating. >>> >>> >> >>Only if it is superfluous code. Some very relevant and proper code makes >>things faster, such as use of a good algorithm. It isn't necessarily gold >>plating. > > If the speed was not required and the change was made to increase > the speed, then it is goldplating. > > I often write code that is not optimal for speed, because it is > easier to maintain. If the code had to be faster, I would modify it. > If it is fast enough, why bother? There are enough other things to > do. I focus on making the code clear before anything else. Then I make sure it's correct -- this is much easier when it's already clear. Then, if it turns out to be necessary, I worry about making it fast -- again, this is much easier if you have clear correct code to start from. First rule of performance tuning: the problem is never where you thought it was going to be. -- Jim Janney