coding tips : Java Glossary
- coding tips
I have been writing code professionally for 50 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Any time you find yourself wondering which of two variables you should be using, globally rename them for
- 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.
- 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.
- 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.
- 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,
- Read my tackling essay about tips for solving difficult problems.
- Read my unmaintainable code essay. Keep in mind it is tongue in cheek.
- 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.
- Code is like a garden. If you don’t constantly keep weeding/refactoring it, it will deteriorate
through routine maintenance.
- 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.
- 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.
- 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
- Write personal programs and scripts you run periodically to check for consistency and for errors you
personally commonly tend to make.