Comments – Building Blocks – 1Z0-829 Study Guide

Comments

Another common part of the code is called a comment. Because comments aren’t executable code, you can place them in many places. Comments can make your code easier to read. While the exam creators are trying to make the code harder to read, they still use comments to call attention to line numbers. We hope you use comments in your own code. There are three types of comments in Java. The first is called a single-­line comment:

// comment until end of line

A single-­line comment begins with two slashes. The compiler ignores anything you type after that on the same line. Next comes the multiple-­line comment:

/* Multiple

  • line comment

*/

A multiple-­line comment (also known as a multiline comment) includes anything starting from the symbol /* until the symbol */. People often type an asterisk (*) at the beginning of each line of a multiline comment to make it easier to read, but you don’t have to. Finally, we have a Javadoc comment:

/**

  • Javadoc multiple-­line comment
  • @author Jeanne and Scott

*/

This comment is similar to a multiline comment, except it starts with /**. This special syntax tells the Javadoc tool to pay attention to the comment. Javadoc comments have a specific structure that the Javadoc tool knows how to read. You probably won’t see a Javadoc comment on the exam. Just remember it exists so you can read up on it online when you start writing programs for others to use.

As a bit of practice, can you identify which type of comment each of the following six words is in? Is it a single-­line or a multiline comment?

/*

  • // anteater

*/

  • bear
  • // cat
  • /* dog */

/* elephant */

/*

  • /* ferret */

*/

Did you look closely? Some of these are tricky. Even though comments technically aren’t on the exam, it is good to practice looking at code carefully.

Okay, on to the answers. The comment containing anteater is in a multiline comment. Everything between /* and */ is part of a multiline comment—­even if it includes a single-­line comment within it! The comment containing bear is your basic single-­line comment. The comments containing cat and dog are also single-­line comments. Everything from // to the end of the line is part of the comment, even if it is another type of comment. The comment containing elephant is your basic multiline comment, even though it only takes up one line.

The line with ferret is interesting in that it doesn’t compile. Everything from the first /* to the first */ is part of the comment, which means the compiler sees something like this:

/* */ */

We have a problem. There is an extra */. That’s not valid syntax—­a fact the compiler is happy to inform you about.

Classes and Source Files

Most of the time, each Java class is defined in its own .java file. In this chapter, the only top-­ level type is a class. A top-level type is a data structure that can be defined independently within a source file. For the majority of the book, we work with classes as the top-­level type, but in Chapter 7, “Beyond Classes,” we present other top-­level types, as well as nested types.

A top-­level class is often public, which means any code can call it. Interestingly, Java does not require that the type be public. For example, this class is just fine:

  1. class Animal {
  • String name;
  • }

You can even put two types in the same file. When you do so, at most one of the top-­ level types in the file is allowed to be public. That means a file containing the following is also fine:

  1. public class Animal {
  • private String name;
  • }
  • class Animal2 {}

If you do have a public type, it needs to match the filename. The declaration

public class Animal2 would not compile in a file named Animal.java. In Chapter 5,

“Methods,” we discuss what access options are available other than public.

Noticing a pattern yet? This chapter includes numerous references to topics that we go into in more detail in later chapters. If you’re an expe-rienced Java developer, you’ll notice we keep a lot of the examples and rules simple in this chapter. Don’t worry; we have the rest of the book to present more rules and complicated edge cases!