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. 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.

 

Top 10 Tips For Database Design

The following are some of the tips that can help ensure that databases created that can be easily exported and manipulated with the minimum of difficulties.

1. Develop A Prototype – Significant time can be saved by creating the structure in a simple desktop database (such as Microsoft Access) before finalising the design in one of the enterprise databases. The developer will be able to recognise simple faults and makes changes more rapidly than would be possible at a later date.
2. Split database structure into multiple tables – Unlike paper-based structures, databases do not require the storage of all fields in a single table. For large databases it is useful to split essential information into multiple tables. Before creating a database, ensure that the data has been normalised to avoid duplication.
3. Use understandable field names – The developer should avoid field names that are not instantly recognisable. Acronyms or internal references will confuse users and future developers who are not completely familiar with the database.
4. Avoid illegal file names – It is considered good practice to avoid exotic characters in file or field names. Exotic characters would include ampersands, percentages, asterisks, brackets and quotation marks. You should also avoid spaces in field and table names.
5. Ensure Consistency – Remain consistent with data entry. If including title (Mr, Miss, etc.) include it for all records. Similarly, if you have established that house number and address belong in different fields, always split them.
6. Avoid blank fields – Blank fields can cause problems when interpreting the data at a later date. Does it mean that you have no information, or you have forgotten to enter the information? If information is unavailable it is better to provide a standard response (e.g. unknown).
7. Use standard descriptors for date and time – Date and time can be easily confused when exporting database fields in a text file. A date that reads ‘12/04/2003’ can have two meanings, referring to April 12^th or December 4^th, 2003. To avoid ambiguity always enter and store dates with a four-digit century and times of day using the 24hr clock. The ISO format (yyyy-mm-dd) is useful for absolute clarity, particularly when mixing databases at a later date.
8. Use currency fields if appropriate – Currency data types are designed for modern decimal currencies and can cause problems when handling old style currency systems, such as Britain’s currency system prior to 1971 that divided currency into pounds, shillings and pence.
9. Avoid proprietary extensions – Care should be taken when using proprietary extensions, as their use will tie your database to a particular software package. Examples of proprietary extensions include the user interface and application-specific commands.
10. Avoid the use of field dividers – Commas, quotation marks and semi-colons are all used as methods of separating fields when databases are exported to a plain text file and subsequently re-imported into another database. When entering data into a database you should choose an alternative character that represents these characters.

And DAMN it’s been a long time since I’ve put something here. I’m not forgetting about the site… just the new job has been taking quite a bit of time out of my leisure activities, this website is one of them. I made quick work of the dozens of spams that got through the filter and updated WordPress.

Also, another problem is I have started using Linux. I’ve been running a mix of Linux and XP at home lately to get a feel of the environment and hope to shift entirely to Linux on the day.

Let’s hope that the next post isn’t so far out. In fact, I promise the next thing I write will be sooner rather than later. 😉

The Singleton Pattern

A design pattern is a general solution for a common problem in software design. The idea is that the solution gets translated into code and applied in different situations where the problem occurs.

One of the commonly used creational patterns is the Singleton pattern. It describes a technique for ensuring that only a single instance of a class is ever created. The technique takes the following approach: don’t let anyone outside the class create the instance of the class. Typically, singletons are created to reduce the memory requirements. You can implement this approach in many different ways.

One of the ways is to make the constructor of the class private or protected and providing a static method which returns an object of the class. By this you can guarantee that only one instance is shared among all. Also, if you know the one instance being created will be the subclass, make the parent class abstract and provide a method to get the current instance. Similar ways of restricting class creation can be found throughout the J2SE standard libraries.

At this point you might think that restricting access to a constructor automatically makes it a Singleton. It doesn’t. An example for that is the Calendar class. The Calendar class constructor is protected, and the class offers a getInstance () method to get an instance of the class. However, each call to getInstance () method gets a new instance of the class. So that is not singleton.

When you create your own Singleton class, make sure that only one instance is ever created:


public class MySingleton{
    private static final MySingleton INSTANCE = new MySingleton ();
    private MySingleton () { }
    public static final MySingleton getInstance() {
        return INSTANCE;
    }
}


The static method, getInstance (), returns the single instance of the class. Note that even if the single instance needs to be a subclass, you don’t have to change the API.

Theoretically, you don’t need the getInstance () method because the INSTANCE variable could be public. However, the getInstance () method provides the flexibility in case of future system changes.

The Singleton pattern is useful if you know you only have a single resource, and need to share access to the state information of that single instance. Identifying the need for the Singleton pattern at design time can simplify development. However, some times you are not aware of the need until a performance problem leads you to refactor code and use the pattern at a later time. For example, you might discover that system performance is degrading because your program is creating instances of the same class to pass the state information. By changing to the Singleton pattern, you avoid recreating the same object. This frees up time the system uses to recreate the object, and saves the time the garbage collector needs to free those instances.

In short, use the Singleton pattern when you want to ensure that one, and only one, instance of the class is ever created. If your constructor doesn’t require any operations, provide an empty private constructor (or a protected constructor if you need to subclass). Otherwise, by default, the system will provide a public constructor, something you don’t want when working with a Singleton pattern.