Jez Higgins

Freelance software grandad
software created
extended or repaired


Follow me on Mastodon
Applications, Libraries, Code
Talks & Presentations

Hire me
Contact

Older posts are available in the archive or through tags.

Feed

The Forest Road Reader, No 94

Listening to Sticky Wickets, the new album by The Duckworth Lewis Method. It's rather lovely and this review at The Quietus explains why.

My Java "modernisation" guidelines thus far :

  • Unused parameters on private methods. Get rid of them.
  • There are almost certainly methods and indeed whole classes that are not used. While I'm not an uncritical advocate of IDEs, modern Java devtools do an excellent job of highlighting dead code. Be aware of code called from JSPs/dynamically loaded classes/generated code, but don't be afraid to whip stuff out.
  • Generics will save you a whole load of typecasts. Remember you can generify (is that a word?) methods as well as interfaces and classes.
  • Covariance is also your friend.
  • If you find a ListIterator in your code, you can almost certainly replace it with an Iterator. If you can't, there's probably something weird going on that you should look at.
  • If a Java method returns a List or a Set or a Collection, I'd lay odds it could return an Iterable with no loss of function.
  • If you return an Iterator, consider returning an Iterable instead.
  • There's lots of really good library code available. Use it. Use it for inline stuff, use it to replace classes, use it to replace whole families of classes. It's fine.
  • Mind your language. Java now is not what Java was then. Use the new loop constructs, string switches, autoclose, multi-catch, and all that good stuff.

Compare and contrast - Boom Boom Afridi vs Boom Boom Mancini.

Of course you're digging around working with old code, it's because you want to change it in some way so all the usual software stuff applies too - do the simplest thing that could possibly work, refactor mercilessly, you ain't gonna need it, once and only once. Lean on your tests and write new tests as you go. If there aren't any extant tests, you've got to go a bit more carefully but you can still write tests to capture existing behaviour before you go changing it. In my current case, there are plenty of tests for some parts of the system and they've been very useful. Other parts of the code are less well served. I've added approximately twice as many tests as I've removed and I'm doing ok - I've put some good new stuff in and not obviously broken anything yet.


Tagged cricket, java, and warren-zevon


Jez Higgins

Freelance software grandad
software created
extended or repaired

Follow me on Mastodon
Applications, Libraries, Code
Talks & Presentations

Hire me
Contact

Older posts are available in the archive or through tags.

Feed