Page 98 - Introduction to Programming with Java: A Problem Solving Approach

64 Chapter 3 Java Basics
book’s Web site that step you through the compilation and execution of a few simple Java programs. We recommend that you now take the time to work your way through one or more of those tutorials. The rest of this section covers some basic concepts related to compilation and execution. Be aware that we cover these concepts plus additional details in the tutorials.
After entering a program’s source code on a computer, save it in a file whose name is comprised of the class name plus a .java extension. For example, since the Dream program’s class name is Dream, its source-code filename must be Dream.java.
After saving a program’s source code in an appropriately named file, create Java bytecode6 by submit- ting the source code file to a Java compiler. In compiling the source code, the compiler generates a bytecode program file whose name is comprised of the class name plus a .class extension. For example, since the Dream program’s class name is Dream, its bytecode filename will be Dream.class.
The next step after creating the bytecode program file is to run it. To run a Java program, submit the bytecode program file to the Java Virtual Machine (JVM).
3.9 Identifiers
So far in this chapter, you’ve learned Java by looking at code. Eventually, you’ll need to learn it by writing your own code. When you do so, you’ll need to pick out names for your program components. Java has cer- tain rules for naming your program components. We’ll look at those rules now.
An identifier is the technical term for a program component’s name—the name of a class, the name of a method, and so on. In our Dream program, Dream was the identifier for the class name, and main was the identifier for the method name. Apago PDF Enhancer
Identifiers must consist entirely of letters, digits, dollar signs ($), and/or underscore ( _ ) characters. The first character must not be a digit. If an identifier does not follow these rules, your program won’t compile.
Coding-convention rules are narrower than compiler rules when it comes to identifiers. Coding con- ventions suggest that you limit identifiers to just letters and digits. Do not use dollar signs, and (except for named constants—to be described later) do not use underscores. They also suggest that you use lowercase for all your identifier letters except:
• Start class names with an uppercase letter. For example, our Dream class starts with an uppercase D.
• Run together the words in a multiple-word identifier, using an uppercase letter for the first letter in the second word, third word, and so on. For example, if a method prints a favorite color, an appropriate
method name would be printFavoriteColor.
Perhaps the most important coding-convention identifier rule is the one that says identifiers must be descriptive. Returning to the example of a method that prints a favorite color, printFavoriteColor is plenty descriptive. But how about favColor? Nope, not good enough. Some programmers like to use ab- breviations (like “fav”) in their identifiers. That works OK sometimes, but not all that often. We recommend staying away from abbreviations unless they’re standard. Using complete and meaningful words in identi- fiers promotes self documentation. A program is self-documenting if the code itself explains the meaning, without needing a manual or lots of comments.
If you break a coding-conventions rule, it won’t affect your program’s ability to compile, but it will de- tract from your program’s readability. Suppose you have a sngs method that prints a list of the week’s top
6 Bytecode, defined in Chapter 1, is a binary-encoded version of the source code. The computer cannot execute source code, but it can execute bytecode.