Tag Archives: code

design, development, java, technology

ten commandments for Java programmers

There are many standards and best practices for Java Developers out there. The article 10 Commandments for Java Developers outlines ten most basic rules that every developer must adhere to and the disastrous outcomes that can follow if these rules are not followed. Briefly summarizing the 10 commandments:

    1. Add comments to your code. – It is true comments do not literally contribute to the functionality of a program. But time and time again you return to the code that you wrote two weeks ago and, for the life of you, you cannot remember what it does!
    2. Do not complicate things. – Developers tend to come up with complicated solutions for the simplest problems. We introduce EJBs into applications that have five users. We implement frameworks that an application just does not need. We add property files, object-oriented solutions, and threads to the application that do not require such things. For those who do not know any better, I recommend reaching out to the more experienced programmers for advice.
    3. Keep in Mind – “Less is more” is not always better. – Code efficiency is a great thing, but in many situations writing fewer lines of code does not improve the efficiency of that code.
    4. No hard coding, please. – Developers often forget or omit this rule on purpose because we are, as usual, crunched for time. But maybe if we had followed this rule, we would not have ended up in the situation that we are in. How long does it take to write one extra line of code that defines a static final variable?
    5. Do not invent your own frameworks. – There are literally thousands of frameworks out there and most of them are open-source. Many of these frameworks are superb solutions that have been used in thousands of applications. We need to keep up to date with the new frameworks, at least superficially. One of the best and most obvious examples of a superb widely used framework is Struts. This open source web framework is a perfect candidate to be used in web-based applications.
    6. Say no to Print lines and String Concatenations. – I know that for debugging purposes, developers like to add System.out.println everywhere we see fit. And we say to ourselves that we will delete these later. But we often forget to delete these lines of code or we do not want to delete them.
    7. Pay attention to the GUI. – No matter how absurd it sounds; I repeatedly observe that GUI is as important to the business clients as functionality and performance. The GUI is an essential part of a successful application. Very often IT management tends to overlook the importance of GUI. Many organizations save money by not hiring web designers who have experience in design of “user-friendly” applications. Java developers have to rely on their own HTML skills and their limited knowledge in this area.
    8. Always Prepare Document Requirements. – Every business requirement must be documented. This could be true in some fairy tale, but it is far from that in the real world. No matter how time-pressed your development is, no matter how tight the deadlines, you must always make sure that every business requirement is documented.
    9. Unit-test. Unit-test. Unit-test. – I am not going to go into any details as to what is the best way to unit-test your code. I am just going to say that that it must be done. This is the most basic rule of programming. This is one rule that, above all, cannot be omitted. It would be great if your fellow developer could create and execute a test plan for your code, but if that is not possible, you must do it yourself. When creating a unit test plan, follow these basic rules:
      1. Write the unit test before writing code for the class it tests.
      2. Capture code comments in unit tests.
      3. Test all the public methods that perform an “interesting” function (that is, not getters and setters, unless they do their getting and setting in some unique way).
    10. Remember – quality, not quantity. – Do not stay late (when you do not have to). I understand that sometimes production problems, urgent deadlines, and unexpected events might prevent us from leaving work on time. But, managers do not appreciate and reward their employees because they stay late on regular basis, they appreciate them because they do quality work. If you follow the rules that I outline above, you will find yourself producing less buggy and more maintainable code. That is the most important part of your job.

 

Standard
fun, general

What Kind of Programmer Are You?

 

An interesting categorization of different types of programmers is posed in 10 types of programmers you’ll encounter in the field . Of course, most people would be combinations of several of the types. Briefly summarizing the ten types:

  • Gandalf: Bearded old guy with lots of wisdom but also lots of time to talk at great length about how he acquired it.
  • Martyr: Workaholic. Lives under his desk.
  • Fanboy: Very obsessive (both in and out of the office) that they have no clue when it comes to doing what they were hired to do.
  • Vince Neill: 40-something hippie with technical knowledge and persistent hangover.
  • Ninja: Never seen, but puts in loads of work, evidenced only by commit logs.
  • Theoretician: Knows everything in theory, expounds at length, but can’t do the simplest practical thing on his own.
  • Code cowboy: Hacker, spaghetti code producer, no method, just madness.
  • Paratrooper: Last ditch troubleshooter. Bruce Willis behind enemy lines.
  • Mediocre man: “Good enough” is always good enough.
  • Evangelist: Knows about tools, preaches about them at length, but doesn’t know much about implementation.

Of course, all the “he” and “his” instances above could just as well be “she” and “her”. So… the question is where do you fit in or which of these combinations most closely resemble you? And what are some of the awful stories you have about others, who shall remain nameless, who fit into the other categories?

Standard