digg

Facebook Connect Join Digg About

10 tips on writing reusable code

hoskinator.blogspot.com — Really good tips how to write reusable code.

Who dugg this? Made popular Jun 20, 2006

Digg DudeWhat is Digg?

Digg is a place for people to discover and share content from anywhere on the web. Digg surfaces the best stuff as submitted and voted on by the community. Take the Tour to learn more.

50 Comments

show profanity settings
expand all
  • duniyadnd, on 10/12/2007, -0/+19Forgot one part... DOCUMENTATION!!! No many are going to re-use your code without that, no matter how good it is.
  • thewebguy, on 10/12/2007, -2/+16well at least he made the main theme of the article modular so he could re-use it in most of the tips
  • Bogtha, on 10/12/2007, -0/+12> 4. Remove the business logic or main code away from any framework code.

    This is just a specialisation of a general technique. You should divide your codebase into separate conceptual areas, with each area taking responsibility for implementing a particular concept and no more. The interaction between these areas should be through documented APIs only.

    This applies not only to business logic and framework code, but most other parts too. For instance, if you separate your interface from your business logic, you can take the guts of your program and turn it into a web application. If you separate your business logic from your data storage layer, you can rip out the data storage layer and replace it with something that works off a web service. And so on.

    Basically, if you think there's a good chance you will want to use a particular piece of code elsewhere, make sure it does only the particular task at hand and doesn't include unnecessary stuff like storage or interface. If it does more, you're stuck either bringing the extra stuff along or rewriting the code to take out the unwanted stuff.

    The article is incredible vague, you can't even class some of these as tips they are that short. #8 and #9 are essentially re-stating the article title.
  • Bloodwine, on 10/12/2007, -0/+10Over-engineered code is just as bad as spaghetti code. Reusability is good, don't get me wrong, but sometimes projects become so abstract and flexible that it'd be easier to maintain a mound of spaghetti code.
  • Sartori, on 10/12/2007, -1/+11Tip 11 - remember when to make code non-reusable, and do it wisely. Nothing sucks more than a hugely generic system which has few or no concrete uses - sometimes your code actually has to knuckle down and do something itself! My POV may be slightly different, I program console games...
  • dbit483, on 10/12/2007, -2/+12IMO This article was all fluff, with no concrete examples or concepts. My favorite "7. Don't write code that isn't needed."

    So that's where I went wrong, that flux capacitor code was totally unneeded!
  • rprouse, on 10/12/2007, -0/+9@MrSkrilla - I agree with you on the unit tests, especially if they are commented as to why you are testing various conditions. I disagree with your comment on the comments though. If you update code and do not update the comments, especially those that document the method and are used to auto-gen documentation, then you are not properly commenting your code. Also, comments are much more likely to be maintained than specification documents.

    It is like saying "X is not useful, because some people may not do or maintain X." It doesn't mean that X is not useful, only that you are not following the guidelines set out by yourself or your development team.
  • Tiak, on 10/12/2007, -6/+14Is it just me, or do WAY too many top 10s make it through digg?
  • SamKellett, on 10/12/2007, -1/+9@Darwin: I've seen you call several story authors a "noob" and never once have you explained why you think they deserve that title.

    Here's a tip: Stop doing it or explain your thoughts on the matter from an objective position.
  • Kupotek, on 10/12/2007, -3/+10People love top tens, it gives them a sense of order.
  • evilTak, on 10/12/2007, -0/+5Tip 1: spend more time coding, and less time trying to associate the real world to sci-fi movies and space operas.
  • carlhungus, on 10/12/2007, -0/+5Is it just me or do 5 and up seem kind of obvious and not useful?:
    9. Be more Modular - make your code more modular, think modular, be modular.
    Reminds me of "how to make money in the stock market: buy low sell high"

  • noisyb, on 10/12/2007, -1/+6Being an lazy ass (in a positive way) helps a LOT in writing reusable code.

    That goes on until you can start a new project and (ideally) all you have left to do is writing structs.
  • Moocat, on 10/12/2007, -0/+4Well, the point of doing reusable code is so your projects won't go over time when you make your second, third and fourth projects. Doing it once well tends to work through multiple projects. Personally I have anywhere from 3-4 projects on my plate at any given time and 1-2 of them in the active development stage. While coding the most OOP way you can from scratch can be long in development, once it's done, doing a second time shouldn't take nearly as long since you can reuse the old stuff if coded properly. If you continue in this practice I pretty much guarantee you'll start coming under budget, under time line after the second or third one. The problem is people nay say it before they even try this method or quit halfway through the first time. The key is consistency.

    P.S. I also realize sometimes management might screw with your development which might screw up this whole thing. In that case, OOP, procedural or whatever you do isn't going to be good enough anyway. If your management doesn't understand process...well...I don't know what to tell you... And yes, there are still some very good instances for using non-OOP code, like projects under 6 months with light user usage and small functionality or single use projects.
  • arnor, on 10/12/2007, -2/+5For elmigs:

    1. Keep the code DRY. Dry means Don't repeat yourself. This is one of the main changes I have tried to bring in. Always try to eradicate duplication and if you find any then move remove the duplication to a relevant place. Sometimes this has lead me to create Static Helper classes or sometimes move it to the class it makes most sense to have it.

    2. Make a class/method do just one thing. This is along the lines of the advice of giving the class only one reason to change. This often means creating methods that other methods use but this helps to make the methods/classes simple and less coupled.

    3. Write unit tests for your classes AND make it easy to test classes. Writing code that is easy to test is decoupled. If you write code and are thinking about writing a unit test for it then you tend to split up the code into smaller testable chunks.

    4. Remove the business logic or main code away from any framework code. Following the rules above will help this. An example I have seen is code that is inside Struts Actions classes, this code is practically impossible to reuse because of all the Struts dependencies that it now linked with.

    5. Try to think more abstractly and use Interfaces and Abstract classes. Try to hide dependencies of code behind a more Generic interface/abstract class. The benefit this gives the code is it creates a flexible point in the code where you can then hide future changes behind.

    6. Code for extension. Write code that can easily be extended in the future. This is particularly true with the above point. If you write code that uses interfaces then you can extend that interface at a later point.

    7. Don't write code that isn't needed. Do the simplest thing possible. Don't waste your time adding methods and classes that might be used in the future. Keep the code simple and focused on what you are trying to deliver. I think I read/heard Josh Bloch say once that "if in doubt, leave it out". Basically who wants to write code that no one (including yourself) is going to use again.

    8. Try to reduce coupling. When writing code think about the links and coupling the code is creating, does it need to be linked to those other classes.

    9. Be more Modular - make your code more modular, think modular, be modular.

    10. Write code like your code is an External API. Imagine the code you are writing is a self contained component.
  • Kruncher, on 10/12/2007, -0/+3Except the author states that these are not in any order.
  • Kruncher, on 10/12/2007, -1/+4Well, it looks like Darwin is reusing something....
  • smhill, on 10/12/2007, -0/+3Here is a much better source for writing better code:
    http://mindprod.com/jgloss/unmain.html
  • elmigs, on 10/12/2007, -1/+4I think is missing the most important thing:

    0. Comment your code: Second to the code itself its the most important reference for understanding what a piece of code does.The syntax of some langauges is more readable than others (python vs pearl) but never the less comments are basic. Keep this in mind: good programing involves good comments.
  • markr, on 10/12/2007, -0/+3"It wasn't going to be ten until I got to 8 and then thought no one writes 8 tips, lets add two more on."

    At least they're honest! "8 tips on writing reusable code - + 2 made up tips to pad it out..."
  • brownb2, on 10/12/2007, -0/+2Pffft newbie programmers.

    Using the Xtreme Programming paradigm (assumed with point 7 "Don't write code that isn't needed.") points 6 and 7 conflict - don't try and second guess what you may or may not need in future.
  • ThinkFr33ly, on 10/12/2007, -0/+2This could also be called "ten tips to make sure your project is late or cancelled."

    Sometimes writing reusable code is not worth the effort. In many cases, designing a class for "extension", as he calls it, is a recipe for disaster... especially in Java.

    Java treats all methods like virtual methods. Any method in a class can be overridden by a class inheriting from it. Since you have to explicitly seal (force non-virtual) methods in java programmers often just say "well, I won't do that and therefore my class is now extensible." If you didn't *explicitly design* your class to be inherited from you should seal *all* your methods. (Or just seal the class itself.)

    C# takes the opposite approach, which is only somewhat safer. All methods are considered non-virtual unless you explicitly mark them as virtual. This is better only insofar as it makes is more likely that the inexperienced programmer doesn't shoot themselves in the foot. (And it makes method execution slightly faster.) But many coders will say "oh, well I at least want the option to make this thing extensible, so I'll mark it as virtual and be done with it."

    Again, it takes very careful design to make sure a class is "inheritance happy". That means it takes a lot of time and effort and it should *only* be done when that was a design goal from the very beginning.

    Honestly, reusing code is a great thing... but, usually, the reuse happens long after a particular project was created. You should write your code in such a way that makes sense for the *current* project, and if later you discover a place where you could reuse some code you can go back and refactor.

    If you start from the get go with the idea you're going to create the world's most reusable, modular, object oriented framework that has ever existed, you'll end up with a lot of great code but no product because your company cancelled it 6 months ago since you had nothing to show for it that meant anything to the people with the money.
  • PrisonerOfPain, on 10/12/2007, -0/+2@evilTak: Since when is Alice in wonderland sci-fi?
  • geronimo, on 10/12/2007, -0/+2Just tell the boss man to be patient, the extra work going into the design will result in less time coding. They always understand this! ;)
  • geronimo, on 10/12/2007, -1/+3Here's my technique that works and stands the test of time.

    Write down the outline of what your code does and group the tasks. Now write pseudo code that handles _all_ the cases you can think of for each labeled group... then detail more pseudo code.. Now if in doing this you find out your hairy pseudo code does the same thing as previous pseudo code, instead of writing the duplicate code, write down the group label that it's under.

    After you've done this, you have just labeled all the redundant code so you have a better idea of the design, objects, what gets re-used. Spend hours doing this in the library and get it right, then you'll spend less than an hour ripping out beautiful code.
  • countzen, on 10/12/2007, -0/+2It's not reusable code, that's rarely useful; things change all the time; and most of the things that won't change for a while has been already written.

    It's reusable DESIGN that's important. And that leads to Design Pattern, but well, if you know one, you know the other.

    Just google it, it's all over the place.
  • bpapa, on 10/12/2007, -0/+2No, that's a valid concern actually. Many will say "OK I need to write this class, and I bet I'll need this methods", and then they write a bunch of methods and some go unused. The point is don't write something until you really need it.
  • ReaperUnreal, on 10/12/2007, -0/+1You know, I bet the guy who wrote the article is the kind of guy who would put 4 or 5 layers of abstraction on a program and then wonder why its running so slowly. The tips are only good if you use them in moderation. You don't need to write a modular library for a small program. You don't need abstract classes to write Hello World.
  • Moocat, on 10/12/2007, -0/+1Good for writing reusable code, not so good for a project on a timeline or pushy bosses :)
  • ManxStef, on 10/12/2007, -0/+1Every programmer should own a copy of Steve McConnell's "Code Complete" (now in its Second Edition). It's an absolute gem, full of practical advice on how to write useful, reusable code and is highly recommended.
  • inactive, on 10/12/2007, -1/+2funny to see that "Comment your code" wasnt on the list.
  • ThinkFr33ly, on 10/12/2007, -1/+2Moocat - "While coding the most OOP way you can from scratch can be long in development, once it's done, doing a second time shouldn't take nearly as long since you can reuse the old stuff if coded properly."

    Except that in any even moderatly complex system it is almost impossible for even a seasoned developer to accurately predict the needs of future projects with regards to libraries created for your current project.

    In the end you'll usually end up spending a similar amount of time fixing or modifying your libraries as you would just refactoring as necessary after the fact, yet you spent far more time up front trying to anticipate the needs of the other projects.

    In general, you should always attempt to slice systems into verticle pieces which represent a fully functioning part of the overall system. This will result in being able to show the people paying for the project that you're making progress. If you spend months creating an O/R mapper or set of domain objects but have nothing that actually works from start to finish with regards to the overall project, you're far more likely to never finish that project.

    In general, the quicker you are to get something into the customer's hands, the better the chance you succeed, even if that deliverable is only one small part (verticle slice) of the overall system.

    As you create the additional slices you will obviously have to spend time integrating them. Sometimes you will find yourself reusing code, sometimes not. The point is that you'll almost never be able to accurate predict the needs of the various components ahead of time and so spending time on that is almost always wasted.
  • Moocat, on 10/12/2007, -1/+2@dbit483

    You weren't coding an EVE Online program then. I
  • afx1, on 10/12/2007, -0/+0Most important tip of the ten (IMO):

    "10. Write code like your code is an External API. Imagine the code you are writing is a self contained component."
  • elmigs, on 10/12/2007, -2/+2@arnor Thank you! :D
  • elmigs, on 10/12/2007, -1/+1@ ThinkFr33ly:
    You can save a lot of typing using extensios and its also bindend to the design pattern.
  • pornel, on 10/12/2007, -2/+2If that's the case, then it's not good, reusable code and you're at square 1.
  • crossers, on 07/14/2008, -0/+0yeah , good!it helps! thanks!
    http://www.leannrimes.info
    http://www.shpe-sac.org
    http://www.pmidsig.org


  • danimal0416, on 10/12/2007, -0/+01. on time
    2. within budget
    3. good quality

    Pick any two.
  • perogi21, on 10/12/2007, -2/+0@ ThinkFr33ly
    QFT!
  • raindogmx, on 10/12/2007, -4/+2CharlesDarwin: survival of the fittest, only a moron can win... you seem like the moronest of them all yourself and a classic kind of moron at that.
  • MrSkrilla, on 10/12/2007, -7/+5actually... documentation in the form of comments is NOT GOOD... when the code if modified at a later point the comments are not always updated so the next person to use the code read the comments and thinks it does something it doesn't!
    What is important is Unit Tests! With Unit tests you can define what your function does, how it handles error cases, and can alert you if you modify something that breaks the function. Also, by making your functions unit testable you are reducing coupling which is great for reusing code.
  • elmigs, on 10/12/2007, -3/+1ugggggh blogspot is blocked in my company, can anybody be nice and post the tips here?

    Thanks a lot.
  • surfing, on 10/12/2007, -2/+0you think it's bad now, wait until the end of the year.
  • MorningCoder, on 10/12/2007, -11/+6Free your mind. Stop trying to write reusable code and write reusable code. Follow the white rabbit. I don't even see statements, functions, or classes in the code. I see only reusable pattens and components.

    That works for me.
  • l0ne, on 10/12/2007, -9/+4"Do, or do not. There is no try."
  • MrSkrilla, on 10/12/2007, -6/+1This is just ripping of the "Pragmatic Programmer" book series. NO DIGG
  • macatak, on 10/12/2007, -10/+0figure it out
  • CharlesDarwin, on 10/12/2007, -14/+2Nobody cares what a noob like you thinks, so just shut the ***** up. ;)
    Here are a couple of tips to help you with that.

    Tip 1 - Shut the ***** up

    Tip 2 - Repeat 1 as much as necessary
  • CharlesDarwin, on 10/12/2007, -27/+4Who the hell is this noob (who wrote the article), and why should I care? I have 2 tips for this guy to not be a moron.

    Tip 1 - Don't be a moron

    Tip 2 - Repeat 1 as much as necessary

  • Add a Comment

    Login or register to comment!
    Or, sign-in super fast with your Facebook account ...


© Digg Inc. 2009 — Content created and posted by Digg users is dedicated to the public domain | Terms of Use Updated | Privacy Policy
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.