1.3 The "Use Clause" Style Issue

[ Table of Contents ] Prev ] Chapter Overview ] Next ] [ Glossary/Index ]

The topic covered here is purely a matter of style. We show you two alternative ways of writing the Show_Date procedure, both of which do exactly the same job as the version on the previous page, and with identical performance. The issue is one of readability and human understanding. The functionality and performance of the resulting, compiled program are unaffected.

The first alternative version uses a feature known as the use clause, another kind of context clause. For example, the "use Ada.Calendar;" line in the following code makes it unnecessary to write "Ada.Calendar." as a prefix in a number of places in both the declarative and executable parts. This makes the code far less verbose and, in some ways, easier to read. But there is a disadvantage -- see below.

First Alternative - Using the Use Clause

with Ada.Text_IO;                 -- with clauses
with Ada.Calendar;
use  Ada.Text_IO;                 -- use clauses
use  Ada.Calendar;
procedure Show_Date is
                                  -- declarative part
  The_Time  : Time;
  The_Year  : Year_Number;
  The_Month : Month_Number;
  The_Day   : Day_Number;

begin                             -- executable part

  The_Time  := Clock;
  The_Year  := Year(The_Time);
  The_Month := Month(The_Time);
  The_Day   := Day(The_Time);

  Put_Line("Today's Date:");
  Put_Line("  Year = "  & Year_Number'Image(The_Year));
  Put_Line("  Month = " & Month_Number'Image(The_Month));
  Put_Line("  Day = "   & Day_Number'Image(The_Day));

end Show_Date; 

While the above code is less verbose than that on the previous page, one cannot look at it and deduce the origin of the various types and subprograms employed. (This may not be a problem if one happens to be familiar with the details of the two predefined packages that are "withed in" and "used"). Thus, while the code is easier to read, in one sense, it is not as self-defining as the previous code, and is harder to understand, in another sense. If you imagine a more complex program, where one program unit withs in a dozen other program units (some predefined and some user-defined), you can appreciate how the lack of such self-defining code could lead to problems in understanding and maintaining code. Some Ada development organizations forbid, or strongly discourage, the use of the use clause for this reason. Others maintain that with modern tools it is easy to find out where any item is declared, and therefore, use clauses help to reduce verbosity in code and have no serious negative impact.

The second alternative version of Show_Date, listed below, illustrates an interesting way to have "the best of both worlds." It employs a feature of Ada built around the reserved word renames. The two use clauses are omitted, and renaming declarations are added at the beginning of the declarative part. The new package names are very short, and thus serve as abbreviations. The resulting code is considerably less verbose than the original (in the previous section), but retains the desired self-defining property.

Second Alternative - Using Renaming Declarations

with Ada.Text_IO;                     -- with clauses
with Ada.Calendar;
procedure Show_Date is
                                      -- declarative part
  package Cal renames Ada.Calendar;      -- renaming declaration
  package Tio renames Ada.Text_IO;       -- renaming declaration

  The_Time  : Cal.Time;
  The_Year  : Cal.Year_Number;
  The_Month : Cal.Month_Number;
  The_Day   : Cal.Day_Number;

begin                                 -- executable part

  The_Time  := Cal.Clock;
  The_Year  := Cal.Year(The_Time);
  The_Month := Cal.Month(The_Time);
  The_Day   := Cal.Day(The_Time);

  Tio.Put_Line("Today's Date:");
  Tio.Put_Line("  Year = "  & Cal.Year_Number'Image(The_Year));
  Tio.Put_Line("  Month = " & Cal.Month_Number'Image(The_Month));
  Tio.Put_Line("  Day = "   & Cal.Day_Number'Image(The_Day));

end Show_Date; 

We will employ all three styles at different times in subsequent material, but rely heavily on this last alternative, especially in the larger, more complex examples. Note that there is another kind of use clause called the use type clause, covered in a later chapter.

[ Back to top of pagePrev ] Next ]