Code Whispering

Code Whispering

Being a craftsman in development practises is only part of the problem! Structuring and refactoring your code can make it easier to add new functionality and reduce complexity, and make it easier for people to read your code. We'll take a brief look at some principles that help make great software, and the hints that your code can give you about what you can improve.


Alex Curran

March 13, 2015


  1. Code Whispering Can your code tell you what’s wrong?

  2. What makes good code? • Small, single responsibility classes with

    well-defined contracts • Hide implementation details from outsiders • Predictable state • SOLID principles
  3. SOLID Principles Single responsibility Open/closed principle Liskov’s substitution principle Interface

    segration Dependency inversion
  4. What’s a code smell? "a code smell is a surface

    indication that usually corresponds to a deeper problem in the system" Martin Fowler • Long methods • God objects (cough, Context) • Subclassing
  5. Check your imports! • Lots of imports can imply lots

    of responsibilities • Perhaps some obvious delegation or leaking of implementation detail // Animations
 import android.animation.Animator;
 import android.animation.AnimatorSet;
 import android.animation.ObjectAnimator;
 // Widget?
 import android.appwidget.AppWidgetManager;
 // Copy/pasting
 import android.content.ClipData;
 import android.content.ClipboardManager;
 import android.content.ComponentName;
 import android.content.ContentValues;
 import android.content.Context;
 import android.content.Intent;
 // Data
 import android.database.Cursor;
 // UI
 import android.os.AsyncTask;
 import android.os.Build;
 import android.os.Bundle;
 // More data
 // More UI
 import android.view.LayoutInflater;
 import android.view.Menu;
 import android.view.MenuInflater;
 import android.view.MenuItem;
 import android.view.View;
 import android.view.ViewGroup;
 import android.view.inputmethod.InputMethodManager;
 import android.widget.EditText;
 import android.widget.ImageView;
 import android.widget.TextView;
 import android.widget.Toast;
 import com.espian.formulae.lib.BaseContentFragment;
 import com.espian.formulae.lib.R;
 // Rendering
 import com.espian.formulae.utils.AssetImage;
 import com.espian.formulae.utils.EquationParser;
 import com.espian.formulae.utils.Helper;
 // More animations
 import com.espian.formulae.utils.InLeftHideHelper;
 import com.espian.formulae.utils.InRightHideHelper;
 // More rendering
 import com.espian.formulae.utils.SuperAdapter;
  6. Fields and parameters • Make as many fields final as

    possible • Temporary fields often mean an obvious delegate (e.g. lastX and lastY in an activity) • Lots of parameters/constructor args imply lot of responsibility • Many parameters passed around together - is this a thing?
  7. Branching • Avoid an “if” statement if you can •

    Imply two different behaviours • Makes it more difficult to test all the routes • Strategy pattern is a really good idea public void doSomething() {
 public void downloadLargeFile(boolean wifiOnly) {
 if (wifiOnly) {
 if (connectivity.isOnWifi()) {
 } else {
 } public void doSomething() {
 if (preferences.wifiDownloadsOnly()) {
 } else {
 } public void doSomething() {
 DownloadStrategy ds = preferences.downloadStrategy(connectivity);
 public class WifiOnlyStrategy implements DownloadStrategy {
 public void attemptDownload() {
 if (connectivity.isOnWifi()) {
  8. Null checks • Try to avoid setters - required dependencies

    in the constructor • If an interface is optional, define a null implementation - no null checks! • Make use of the @Nonnull and @Nullable annotations public interface MessagesCache {
 Bitmap getContactPhoto(Contact contact);
 void storeContactPhoto(Contact contact, Bitmap bitmap);
 void invalidate();
 MessagesCache NO_CACHE = new MessagesCache() {
 public Bitmap getContactPhoto(Contact contact) {
 return null;
 public void storeContactPhoto(Contact contact, Bitmap bitmap) {
 public void invalidate() {
  9. AsyncTask • Defines how work is done, and the work

    that is done • Not exactly single responsibility • Base class inheritance • Contrast with Executor
  10. Flaky tests • Avoid network as much as you can

    • @SmallTest? All tests should be small! • Fewer integration tests, the better • Threading - mixing how to execute with what to execute • Emulators and UI
  11. Large tests • Large set-up implies complex, badly-defined responsibilities •

    But not always true! • JVM tests are much faster than Robolectric • Pushing Android out of your domain = faster feedback
  12. Metrics • Cyclomatic complexity • Ecomp (imports, conditionals, inheritance) •

    Code coverage before and after test, if it has gone down then new behaviour has been added and it isn’t a refactor!
  13. Structural patterns • Structure code according to responsibility • MVC

    - model-view-controller • MVP - model-view-presenter
  14. More resources • Ecomp project on Github • TDD: Where

    Did It All Go Wrong? • Growing Object-Oriented Software