Introduction to Java programming, Part-1 (14)

Writing good Java code

You've got enough Java syntax under your belt to write basic Java programs, which means that the first half of this tutorial is about to conclude. This final section lays out a few best practices that can help you write cleaner, more maintainable Java code.

Keep classes small

So far you've made a couple classes. In the wake of producing getter/setter sets for even the modest number (by the models of a certifiable Java class) of traits, the Person class has 150 lines of code. At that size, Person is a little class. It's normal (and it's sad) to see classes with 50 or 100 techniques and a thousand lines or a greater amount of source. A few classes may be that huge out of need, however doubtlessly they should be refactored. Refactoring is changing the plan of existing code without changing its outcomes. I suggest that you take after this best practice. 

All in all, a class speaks to a reasonable element in your application, and a class' size ought to reflect just the usefulness to do whatever that element needs to do. Keep your classes firmly centered to do few things and do them well. 

Keep just the strategies that you require. On the off chance that you require a few assistant strategies that do basically a similar thing yet take diverse parameters, (for example, the printAudit() strategy), that is a fine decision. In any case, make certain to restrain the rundown of strategies to what you require, and no more.

Name methods carefully

A good coding pattern when it comes to method names is the intention-revealing method-names pattern. This pattern is easiest to understand with a simple example. Which of the following method names is easier to decipher at a glance?

• a()
• computeInterest()

The appropriate response ought to be self-evident, yet for reasons unknown, developers tend to give techniques (and factors, so far as that is concerned) little, truncated names. Absolutely, a strangely long name can be badly arranged, however a name that passes on what a strategy does needn't be incredibly long. Six months after you compose a group of code, you won't not recollect what you intended to do with a strategy called compInt(), yet clearly a technique called computeInterest(), well, presumably figures intrigue.

Keep methods small

Little strategies are as best as little classes, for comparable reasons. One saying I attempt to take after is to keep the span of a strategy to one page as I take a gander at it on my screen. This practice makes my application classes more viable.

In the event that a strategy develops past one page, I refactor it. Obscure has a superb arrangement of refactoring instruments. More often than not, a long technique contains subgroups of usefulness bundled together. Take this usefulness and move it to another technique (naming it in like manner) and go in parameters as required. 

Restrain every strategy to a solitary employment. I've found that a strategy doing just a single thing great doesn't as a rule take more than around 30 lines of code. 

Refactoring and the capacity to compose test-first code are the most essential aptitudes for new software engineers to learn. In the event that everyone were great at both, it would alter the business. On the off chance that you turn out to be great at both, you will at last deliver cleaner code and that's just the beginning utilitarian applications than a large number of your associates.

Use comments

Please, use comments. The people who follow along behind you (or even you, yourself, six months down the road) will thank you. You might have heard the old adage Well-written code is self-documenting, so who needs comments? I'll give you two reasons why I believe this adage is false:

• Most code is not well written.
• Try as we might, our code probably isn't as well written as we'd like to think.

So, comment your code. Period.

Use a consistent style

Coding style is a matter of personal preference, but I advise you to use standard Java syntax for braces:

public static void main(String[] args) { }

Don't use this style:

public static void main(String[] args) { }

Or this one:

public static void main(String[] args)   {   }

Why? Well, it's standard, so most code you run across (as in, code you didn't write but might be paid to maintain) will most likely be written that way. Eclipse does allow you to define code styles and format your code any way you like. But, being new to Java, you probably don't have a style yet. So I suggest you adopt the Java standard from the start.

Use built-in logging

Before Java 1.4 introduced built-in logging, the canonical way to find out what your program was doing was to make a system call like this one:

public void someMethod() {   // Do some stuff...   // Now tell all about it   System.out.println("Telling you all about it:");   // Etc... }

The Java language's built-in logging facility (refer back to the "Your first Java class" section) is a better alternative. I never use System.out.println() in my code, and I suggest you don't use it either. Another alternative is the commonly used log4j replacement library, part of the Apache umbrella project.

• Tweet
• Share
• Share
• Share
• Share