coding tips : Java Glossary


coding tips
I have been writing code professionally for 51 years. I have thus had lots of time to discover new ways to do things incorrectly. I find new ones every day. Based on that experience, here are some tips to help you in coding computer programs. These will often sound prissy, but they really do save time in the long run.
  1. Tell the computer each fact in only one place. That way, when you change it, the change will be universally propagated. Modern computer languages work hard to thwart you in this endeavor. For example, if you change a Java variable from int to long, you must manually track down all instances of that variable and make manual adjustments to the code. You sometimes have to create tools and cookie cutters to let you explain your desired patterns to the computer only in one place. I implemented my own language Abundance back in 1979 and a future language Bali to make this easier to do. Java has named constants which make it easy for you to change some magic constant in only one place.
  2. When you write code, think to yourself, What will I most likely want to change in future?. Then leave yourself some notes as to all the things you will have to do and check to effect a change. Consider changing the code to facilitate changing, or writing some tools now to automate such changes while what needs to be done is still fresh in your mind.
  3. Write the documentation first. This will help you design easy to use programs. Laziness will push to you create programs easy to explain not easy to code. Further, you will have the docs to guide you during coding. Further, ambiguities that arise during coding will be resolved both in the code and the documentation. If you do the documenatation later, you will not have as much enthusiasm for it. Further, you will know the program too well, and will unconsciously tend to leave out things newcomers don’t know.
  4. To create a program, first write a prototype with the most miminimal imaginable functionality. Then gradually add features one at a time. This way you will spend almost no time debugging since you know where any problem must lie — in the most recently added functionality.
  5. Document the overall intent of each class, method and variable with a succinct one-liner. Make sure that class/method/variable is used for that and only that purpose. If you can’t figure out how to explain it, split the functionality until you can.
  6. Any time you find yourself wondering which of two variables you should be using, globally rename them for increased clarity.
  7. Don’t clone code. Extract the common functionality and specifiy it in once place. Tools like IntelliJ Idea refactor extract method and extract constant is a great help.
  8. We are still stuck in the dark ages in terms of thinking of code as unstructured text. Think of it is a sort of bailing wire database that you can manipulate with programs or mine for information. This means creating as much standardisation and structure as you can in your code. Javadoc was a great step in this direction. Use idioms. When you find a better idiom, convert all your code to the new idiom. Inconsistency destroys your ability to treat your code like a primitive database.
  9. Keep methods short. You should be able to see the whole method on screen at once, unless it has no branching. Constantly use the refactoring tools of your IDE (Integrated Development Environment) to extract chunks of code into their own methods. This will help you find the logic you are looking for and will lead to improved encapsulation. Your code will naturally be much easier to understand and maintain. You want to get rid of as much code as possible that is similar to some other code. Extract the common logic into its own methods. When you get into the habit of doing this, you find your programs became simpler and simpler over time.
  10. Rigidly follow naming conventions. Follow my advice on how to choose good method and variable names. Finding good names for your methods and variables is half the battle. Every time you think of a better name, globally rename.
  11. Read my tackling essay about tips for solving difficult problems.
  12. Read my unmaintainable code essay. Keep in mind it is tongue in cheek.
  13. When you come across a piece of documentation in the code or externally that you find confusing, after you have sorted out what it really meant, rewrite the documentation. It is almost impossible to write and proofread documentation without some time lapse to forget what you meant to say, and see what you really wrote.
  14. Code is like a garden. If you don’t constantly keep weeding/refactoring it, it will deteriorate through routine maintenance.
  15. Avoding cloning. If you do succumb to the temptation, refactor immediately afterwards using your IDE refactoring tools that you don’t actually duplicate code. Clone and variate is the road to hell.
  16. In English composition you learn to vary your way of expressing. For programming, you must do the exact opposite. Be mindlessly obsessively consistent, even when you can see no reason for it. Use tools to enforce mindless consistency. Then it will be easier to make global changes with automated assists.
  17. Do the easy work first. This gives your subconscious time to chew on the more difficult problems. It also gives you time to tidy things up so the difficult problem is not quite so messy. It is also easy to get yourself sat and working if the initial task is easy. Trying to tackle the most difficult task first will lead to procrastination. There is nothing lazy about doing the easy work first. You have to do it all eventually. I find it useful to leave a bit of simple work undone at the end of a day so I have something easy to get me going the next day. Don’t take this to extremes and do easy low priority work that does not really need doing.
  18. Write personal programs and scripts you run periodically to check for consistency and for errors you personally commonly tend to make.

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
no blog for this page
Your face IP:[]
You are visitor number