BT

InfoQ Homepage News Presentation: 10 Ways to Improve Your Code

The next QCon is in New York, Jun 24 - 26, 2019. Save an extra $100 with INFOQNY19!

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

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Excelent !!

    by Erick Pimienta /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks Neal on sharing this 10 points and experience.

  • Sharing Presentation?

    by Erick Pimienta /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Is this presentation available for sharing? If so where I can download.

  • Re: Sharing Presentation?

    by Erick Pimienta /

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Not sure I agree Singleton's are Global Variables.

    by Porter Woodward /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In practice - they are often used as such. In theory - they're not intended as such.

    What I mean is that a Singleton can represent a resource of which there is a single instance. Often a logger or file system object, or some I/O port of which there is a single, physical instance of it. A singleton is thus a valuable way to model a real-world behavior.

    Saying singletons are bad because they have mixed responsibilities, and are not testable - is the same as saying objects are bad because of the same reasons. Essentially you're dealing with bad singletons - which are also _bad_ objects. When they end up being used as a big library of static utility functions - that's when they're bad. At that point you're not dealing with object oriented code anymore, you've gone over to procedural code.

    Properly engineered, and object oriented singletons are fine. Poorly engineered, not object oriented static function libraries are not.

  • Interesting Placement

    by James Moline /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I find it funny that #10 under Coporate Code Smells:

    "We invented our own web/persistence/messaging/caching framework because none of the existing ones was good enough"

    is immediately followed by

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

    Seems a little incongruous.

  • Re: Not sure I agree Singleton's are Global Variables.

    by Dmitry Tsygankov /

    Your message is awaiting moderation. Thank you for participating in the discussion.


    a logger or file system object, or some I/O port of which there is a single, physical instance of it.

    But file system objects (and, therefore, loggers) are essentially the same old global variables! Global variables are in memory, files are on disk. Are there any other major differences? Both can be accessed by any thread if you have pointers to them (or filenames, or port numbers), locked in some way, concurrent access can lead to deadlocks, modularity can suffer whenever any of those things is used, one always has to access those resources in a certain order etc. An IO port is a global variable of type string, with one thread appending data to the end while another thread removes data from the beginning.
    Of course, one has to do something in the end - write to a file or a database or something. But if you try to keep the core of the program clean of those things - you get a more maintainable program in the end. At least that's what I believe in. Some people don't...

  • Re: Not sure I agree Singleton's are Global Variables.

    by Pete Kirkham /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The code example given was the classic singleton anti-pattern - a hardwired, globally accessible single object which cannot be changed. What you seem to be talking about are objects of which there happens to be only one instance in the application (move to a different machine, you get an extra serial port; converting code which assumes a singleton to code which doesn't is a waste of effort).

    If you hard wire the singleton as in the example, you get problems both in testing and when the singleton assumption is violated. If you create single instances of some types in your configuration, then you don't get these problems. You might say that YAGNI for two serial ports, but you do need it whenever you want to mock the object for tests, so even if there is one object in the domain of your first iteration, making it not a singleton gives an advantage.

  • Slide and Presentation Timing issue

    by Adam Zimmerman /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I like this presentation and found it confusing by the end with the timing of the slides and the content in the presentation.

    I think there is a slide and timing issue at about minute 46. Anybody else seeing this? The slide changes to Swing + Ruby when dsl's are being talked about. Then the rest of the presentation is ~1 slide off.

    Is this something that can be fixed?

  • Excellent

    by DSK Chakravarthy /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That is a great work and keen observation from SmallTalk stories. Surprised and unbelievable that these so called modular coding is first identified during 70s and documented by SmallTalk authoers.

    Anyway, is there any possibility to download this presentation and play it offline with our dev folks!!

    Apart of all.. thanks for the knowledge share

  • Like all of this except using reflection of private constructors

    by Declan Whelan /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Awesome presentation! I do have a quibble though.

    I think creating private constructors and using reflection to invoke them is a questionable practice. Constructors should be appropriately visible and reflection should not be used to bypass language visibility when you have other options. Using reflection makes the code more complex, harder to maintain and limits the effectiveness of refactoring tools. And it still does not guarantee the singleton behaviour because reflection can be used anywhere.

    Best to avoid the reflection in this case and make the constructor appropriately visible.

  • Singleton can be useful if used correctly

    by Jean-Simon LaRochelle /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is certainly a pattern that can be misused. However, if you keep in mind the dangers of this pattern I think it can be used with good results. The best Singleton is stateless and of course read-only (the main problem of global variables is that they can be modified anywhere any-time so a read-only Singleton is not a store of global variables in the traditional sense). You can find good (constructive) critical analysis of the Singleton pattern on the Web.

  • Re: Not sure I agree Singleton's are Global Variables.

    by Manjunath Bhat /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Porter, Couldnt agree more with you. You put it very nicely. Singletons should be put to right use, not "abused". That's when it gets messy.

  • Re: Like all of this except using reflection of private constructors

    by Stephan Kennedy /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with Declan.
    I liked the presentation too, except the bit about using reflection to work around the private constructor.

    I would create a public interface for the configuration class and hide the implementation class (which would have a public constructor) by making it visible only within its own package or even within the factory class.

  • Re: Not sure I agree Singleton's are Global Variables.

    by Kevin Wong /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think you're misinterpreting his point. He's not saying that there are not cases where there should only be one instance of an object (although if you're unit testing, there aren't), he's saying it's not the object's responsibility to manage its instances.

    Specifically, I think he's referring to the pattern of a private constructor and a method/field to access the single instance. THAT "Singleton" is evil, indeed. That code using this pattern is horrible to test is solid evidence of excessive coupling, as well as a damning con in its own right.

    Manage your object instances in a central place, e.g., DI container (Spring, Guice).

  • Your message is awaiting moderation. Thank you for participating in the discussion.

    Very nice presentation! Funny and goes smoothly.
    Of course some topic are hard to talk in short time like singleton one...
    I think Singleton becomes bad when it's misused and this happen with all languages, paradigms, etc... When someone learn a new language or a new pattern it's quite common start to use it every where and this is a bad programmer behaviour, doesn't mean the pattern/language is bad ;)

  • Re: Slide and Presentation Timing issue

    by jonty davis /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yeah I find this also at the same place, shame as it is such a great presentation, what a help!!

  • Re: Sharing Presentation?

    by Prodis a.k.a. Fernando Hamasak... /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The link above is wrong.
    The correct presentation can be downloaded in this link:
    qconsf.com/sf2008/file?path=/qcon-sanfran-2008/...

  • 10 Ways to Improve Your Code;Posted by Neal Ford on Apr 15, 2009 03:14 AM

    by Pradipta Dash /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Excellent Presentation & Guide.

  • Thanks

    by Kamal Mettananda /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks a lot for this nice presentation.

    As most of the others, I also feel bad about the use of reflection on singleton.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.