BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Presentation: 10 Ways to Improve Your Code

Presentation: 10 Ways to Improve Your Code

Bookmarks

In this presentation recorded during QCon SF 2008, Neal Ford, an architect at ThoughtWorks, shows 10 ways to write better code. This is practical advice for developers, but application architects can benefit from it too.

Watch: 10 Ways to Improve Your Code (1 hour)

Composed Method

  • Divide your program into methods that perform one identifiable task.
  • Keep all of the operations in a method at the same level of abstraction.
  • This will naturally result in programs with many small methods, each a few lines long.

TDD - stands mostly for test-driven development but can also be viewed as test-driven design.

  • When one uses TDD, he starts thinking about the consumer of the code he is writing. This brings awareness on how his code is going to be used by another.
  • It forces the developer to mock dependent objects, resulting in a clearer picture of the relationship between the objects.
  • TDD encourages the creation of composed methods.

Static Analysis

  • It is quite useful to use tools like FindBugs which analyzes the bytecode to discover bugs.

Good Citizenship – refers to the way classes should react to one another

  • Singletons are a bad choice because they have mixed responsibilities and are not testable. They are the objectual correspondents of global variables.
  • The proposed solution is to create a regular POJO and use a factory to make sure that only one instance gets created.

YAGNI – You Ain’t Gonna Need It

  • One should write only the code that is used now.
  • Avoid speculative development which increases the software entropy of a code.
  • Top 10 Corporate Code Smells:

1. There is a reason that WSAD isn’t called WHAPPY.
2. The initial estimate must be within 15% of the final cost, the post-analysis estimate must be within 10%, and the post-design estimate must be with 5%
3. We don’t have time to write unit tests (we’re spending too much time debugging)
4. We keep all of our business logic in stored procedures
5. The only JavaDoc is the Eclipse message explaining how to change your default JavaDoc template.
6. We have an Architect who reviews all code precheckin and decides whether or not to allow it into version control.
7. We can’t use any open source code because our lawyers say we can’t.
8. We use WebSphere because...(I always stop listening at this point)
9. We bought the entire tool suite (even though we only needed about 10% of it) because it was cheaper than buying the individual tools.
10. We invented our own web/persistence/messaging/caching framework because none of the existing ones was good enough.

Question Authority - Some things should not be done just because that is the custom.

Single Level of Abstraction Principle – everything should be at the same level of abstraction

  • All lines of code in a method should be at the same level of abstraction

Polyglot Programming – use the best language for the problem while maintaining the same platform (JVM/.NET)

Learn Every Nuance – developers benefit from learning nuances of their language

Use the Anti-Objects Pattern – “an anti-object is a kind of object that appears to essentially do the opposite of what we generally think the object should be doing.”

Rate this Article

Adoption
Style

BT