This is something that a lot of books don't cover. I personally feel it is something that is extremely important for any programmer to pay attention to. It will not only help you read your own programs, but anyone else who may have to make modifications. By "Code Styling", I'm referring to the use of indenting, variable naming, white space, commenting, etc.
Java makes some suggestions in this regard, others are left up to the developer.
Remember that Java is case sensitive - HelloWorld, helloWorld, helloworld are all different.
Make sure you give your variables meaningful names. If you've ever try to debug
a program that is littered with if (i==0){.....} you'd know why
it's important. It's a lot easier to know that the code snippet if(denominator==0){...}
is possibly going to make sure that it doesn't perform an illegal division
operation. Having good descriptive variable names also encourages self documenting
code. Self Documenting Code means that just by scanning through it - you can
basically pick up what it is doing. This is a lot more difficult if you have
to remember that j = name and d=date. Even without ever seeing a program before
- a person should be able to pickup that Smart Hello is working with times and
dates and printing messages.
Variable, Object and Method Names - first letter lower case, if it's
made up of compound words - then each successive word begins with uppercase.
Example: sayGoodMorning(), todaysDate, hour
Class Names - first letter that makes up each word in the name is capitalized.
Example: GregorianCalendar, String, NumberFormat
Constants - Capitalized
Example: HOUR, HOUR_OF_DAY, MINUTE
This is almost completely up to the developer. Some use the tab, some use spacing, some use basically nothing. I use two spaces when I indent. For one thing - I can easily scan up and down the code. I don't particularly like tabs - the length changes from editor to editor and sometimes they space too far out and it's hard to scan a program.
Indenting should occur whenever a section of code is starting a new block. You can see this clearly in the Smart Hello program. You can tell what lines fall into the if statements or where a class or method begins and ends, just by scanning the code. This helps out tremendously - especially when you are trying to find an error.
Like indenting, developers take liberties on where they place the curly braces. I always line up the ending brace with it's corresponding starting brace. Again - this allows easy scanning of the code. I can quickly pick out blocks of code - without having to scan all the way to an end of a line. I can easily tell if the code falls in the if statement or outside of it. Again you can see this in the Smart Hello program.
Many developers put the ending brace at the end of the last line in the code block. This forces a person looking at the code to look for the starting braces on the left side and the end braces along the right side of the page. It also makes it extremely difficult if you're trying to find a missing brace.
Remove one of the braces in the Smart Hello program and see the error messages that the compiler generates. Remember: Learn by coding and EXPERIMENTING.
This is one area that a lot of developers don't think about. I try to include white space between logical units of code, i.e., between methods, classes or seperating a section of code that perform a certain operation. Look at Smart Hello to see how this is incorporated to make the code more easily understood and followed.
Most books mention commenting - that's why I've left it last. Documenting your code is one of the most important things you can do. However - I don't think it's neccessarily more important than the others - but if you leave out all the other points made above and at least include good commenting, someone looking at your code for the first time can at least get through it. It's not easy - but it's a lot better than nothing.
Now for an example of SmartHello.java without any commenting, naming conventions, indenting or any other of the points I have made above.
import java.util.*;
import java.text.*;
public class BadSmartHello
{public static void main(String[] args)
{BadSmartHello a=new BadSmartHello();
GregorianCalendar td= new GregorianCalendar();
int h,m,hod,ap;
h=td.get(Calendar.HOUR);
hod=td.get(Calendar.HOUR_OF_DAY);
m=td.get(Calendar.MINUTE);
ap=td.get(Calendar.AM_PM);
a.sT(h,m,ap);
if (hod<12)
{a.sGM();}
if (hod>11 && hod<17)
{a.sGA();}
if (hod>=17 && hod<22)
a.sGE();
if (hod>=22)
a.sGN();}
private void sGM()
{System.out.println("Good Morning World!");}
private void sGA()
{System.out.println("Good Afternoon World!");}
private void sGE()
{System.out.println("Good Evening World!");}
private void sGN()
{System.out.println("Good Night World! I'm going to bed!!!!");}
private void sT(int h, int m, int ap)
{NumberFormat mf=NumberFormat.getNumberInstance();
mf.setMinimumIntegerDigits(2);
String aps;
if (ap==0)
{aps="AM";}
else{
aps="PM";}
System.out.println("The time is - "+h+":"+mf.format(m)+aps);
}
}
This program does EXACTLY what the SmartHello program does - but it is definitely not written for a human to read. It's even smaller - the longest variable name I used was three characters long. You'd have to spend some time to analyze what this program does now. Imagine what it would be like to have to debug a 2,000 line program written like this.
Finally - whatever style you use - keep it consistent. Hopefully you won't choose the BadSmartHello style. Having incosistent style also makes it hard for someone to read your code. If you line up all your braces and then they encounter a line that has the brace at the end - they may actually think it's missing and attempt to add a second one.
Java Tutorial - The Basics ->
<- Java Tutorial - Getting Started
Again if you have any questions, suggestions or problems - e-mail me at rrosetta@hsonline.net.