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.
- 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 increased clarity.
- 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
- 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, globally rename.
- 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
- 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.