XpdWiki

FrontPage
RecentChanges
XtC
FindPage
PageIndex
XpApprentices

Set your name in
UserPreferences

Edit this page

Referenced by
GoodThings
SometimesGoodAndS...
GoodVsEvil




JSPWiki v2.0.52


EvilThings


  • Singleton -- Obviously (hard to test, can you guarantee behaviour of VMs and ClassLoaders?,...)
    • On the other hand if you use a Fowler-style Registry http://martinfowler.com/eaaCatalog/registry.html then they're just regular classes and you can guarantee singleton-ness as long as no-one misbehaves by directly instantiating one.
    • You can have the singletons placed in a registry. If the registry has hide() and restore() you can hide the contents at set up, create your test singleton the way you want and place it straight into the registry, then restore the old registry at tear down. Testing singletons doesn't bother me as much any more (although I still avoid them if I can) -- MarcuS
  • Extends Thread -- Use runnable it's easier to test
    • I've found 15 self starting threads which are actually singletons aswell! Do I get a prize. --OliBye
    • junit.swingui.TestRunner.doRunTest() has an anonymous inner class that extends Thread in-place. Um... cool? Hmm. Jury's still out. --DarrenH
  • Abstracting to hell -- Too much too soon! (it's not big and it's not clever)
  • Blob/God -- 'nuff said
  • Unclear responsibility -- One class does one thing or is one thing
  • Instantiating classes without fulfilling prerequisites -- Constructing a class and then always having to call setSomething before it's usable, happens a lot with Singleton.
  • Unclear actions e.g. self starting threads -- magic is bad
  • catch(Exception e){} -- invisibility is bad, where did it go?
  • Code which adds nothing -- Impossible to test and clutters things up -- See Abstracting to hell
  • Duplicate code -- I really don't want to have to type or read things more than once
  • Declaring to throw Exception -- There's not much I can do unless I know what went wrong
  • myThing -- There must be a better name for this variable
  • Static initialisers -- Rather difficult to test, more Magic (the VM pixies at work)
  • System.exit(0); -- Makes reuse difficult
  • Non final static variables -- Can you say "Global Variable"?
  • final static fields -- they get inlined by compilers (the language spec allows it) and lots of tools don't seem to realise this dependency for recompiling
  • Literal Values:
    • Magic numbers -- Use constants or look at the size of something
    • Literal strings -- Use constants, espetially if you can't spell
  • Using return codes -- If it's an error throw an Exception
  • Not writing Javadoc as you go -- Much better to write when you know what the class does rather than when you've forgotten.
  • Writing Javadoc prematurely -- Avoid 'prematurely' detailed javadoc. Stick with terse overview, package and class comments. (Your JUnits will do for the rest).
  • Writing Javadoc as you go -- If someone reading you code needs a gloss to understand it, re-write it so that they don't.
  • Comments in methods -- Chances are you'd be better splitting the code out into another method.
  • The CLASSPATH enviroment variable
  • .toString() -- Whats that for? Is it a description or a serialisation? Its for debugging
  • Too much beer -- especially the morning after the night before
  • Too much sugar and too much work with too few breaks
  • Code Generator Wizards --- There really is a parallel here with stories about demons. In the literature, evil demons are known to con people into thinking that they can do powerful magic - when really the demon is hacking it for them. As soon as they start to rely on the "powerful magic" that they think they can do, they're doomed. (See Terry Prattchet's take on Faust - "Eric".)
  • Identical comments attached to a pair of non-identical methods or classes - For example seeing the comment "This method recomputes the bogon count using Cartman's algorithm" in front of recalculateBogons() and recalculateDuffons(). Hmmm it smells like recalculateDuffons() has been cut-and-pasted from recalculateBogons() and then hacked around a little. This has a particularly pungent smell when both methods have almost identical implementation.
  • wikispam a slew of which was just removed from his page

Please feel free to comment or add your own

See GoodThings, GoodVsEvil and PunitiveMeasures

Also see TooMuchMagic which provides a list of other EeeveelTings?-- JosephNyirenda. Sometimes extreme acts of evil are necessary...



Edit this page   More info...   Attach file...
This page last changed on 02-Mar-2005 09:41:56 GMT by 128.32.177.91.