programming rules of thumb : Java Glossary

programming rules of thumb
I have been programming professionally for 50 years. Here are some rules of thumb for computer programming that I have learned from painful experience.
  1. When deciding on a set of categories, err on the side of making them too fine. It is easy to mechanically coalesce the categories later for some new purpose, but very difficult to manually recode the data, splitting them into finer categories.
  2. If you find yourself doing some repetitious, monotonous task, take the time to automate it, now. This includes writing monotonous computer code. There are four benefits.
    1. You save the time doing it manually between now and the time the pain reaches the threshold that you finally do automate it.
    2. You will do it consistently, accurately and properly from the get go. When you are automating, you tend to think more carefully about precisely how something should be done.
    3. You won’t have an inconsistent mess to clean up when you finally do get around to automating it.
    4. Writing automating code is much more fun then tedious bullwork.
  3. Tell a computer any given fact in only one place. Lobby to fix up computer languages and tools so that when you change a given fact in any one place, that change is automatically universally propagated. The Java language flagrantly violates this principle with its casts. You specify the type of a variable over and over. Ditto with new where you must respecify the type. You want to work toward a data dictionary, where corporate variables, their names, definitions, bounds, error checks, display formats etc. are all defined in one place, not implicitly buried in thousands of different bits of procedural code, SQL (Standard Query Language) and GUI (Graphic User Interface) layouts. The Internet web also violates the principle. When a web page is retracted, renamed or moved, that fact is currently not automatically propagated to all the links to it. You have a horrible entropy problem and untold hours of wasted human effort maintaining web links.
  4. Be very careful to use consistent vocabulary. Create a glossary if you use any terms in particular project-specific way. The terms may be obvious to you or your coworkers, since you use them consistently in your informal conversations, but they usually highly ambiguous to someone coming in cold. The important thing is rigid consistency. You are not writing a novel. You don’t want to imply subtle differences that are not there. For example, consider the following list of verbs I have seen programmers use to mean format to a string suitable for display to humans. Each has connotations that may or may not have been intended.
    Variants on the Verb Format
    Term Notes
    display implies making visible
    encode to a specific character set, implies a hard to read, external armoured (e.g. base64) or encrypyted form, perhaps with some ugly convention for handling awkward characters.
    enstring like enclose or encapsulate
    format implies alternative layouts. This is what Sun uses. Does not imply any sort of I/O or display as a side effect.
    print implies hardcopy
    render implies a bit map image
    stream implies sending as a stream to disk
    write as in write to a printer or disk
  5. When composing an essay, class or method, always err on the side of splitting it into pieces that are too small. They will inevitable grow. It is much easier later to combine small pieces, if necessary, than split up a big chunk.
  6. Literate naming is the #1 tool to writing maintainable code. Name classes, variables and methods in such a way that in a blind alphabetical listing, related items will be close to each other in the list. Read my essay on how to choose names for methods and variables. Read my tongue in cheek essay on how to write unmaintainable code by malicious selection of arbitrary names. Use the global rename feature of your IDE (Integrated Development Environment) exhaustively to continuously improve your names.
  7. Programming is a team sport. Even if you work alone as an independent contractor much of your success comes from sweet talking people into giving you information and solving problems for you. Computer programmers tend to have bigger than average egos which makes for trouble if you are not aware of the strong need for others to save face. When you explain something, and the other person does not understand, don’t waste time deciding whose fault it is. Simply accept that your explanation was not sufficient for them to get it. Both of you wish it were. There is utterly no point in berating the other person for misinterpreting or failing to understand your explanation. Think like a lawyer. How could someone intentionally twist the meaning of your words? (not that they did). Then set about patiently removing the ambiguities. You can’t rely on their common sense to resolve the ambiguities because common sense only kicks in once they have a general understanding. I like to write essays on something very soon after I have learned it myself, even if that means a few extra errors, that others delight in pointing out. That is when I am most expert on what is not obvious.

CMP homejump to top

available on the web at:
ClustrMaps is down

optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy.
Your face IP:[]
You are visitor number 11.