Programming Style


The aforementioned desired software characteristics may be achieved by applying appropriate programming style. This topic is tightly connected to Chapter 9, which addresses program comprehension. In what follows , we strengthen this connection by illustrating how programming style may influence directly and implicitly program comprehension .

Tasks  
  1. Identify at least three connections between programming style and program comprehension. Illustrate these connections by short stories that may happen in the daily life of software engineers .

  2. There are specific programming style guidelines for specific programming languages (such as C++ and Java). Find such guidelines (several are available on the Web). What aspects of the code do these guidelines address? Select five rules from one of these guidelines and explain their connection to program comprehension.

  3. Identify additional chapters of this book whose topics may have direct connection to programming style.

  4. Look for information about the Y2K bug. What issues related to programming style are connected to this bug?

The most important feature of communicative programming style is that the code communicates itself without the need for comments, explanations , apologies, and so forth. For example, the essence of a variable can be expressed by its name . [1] If one names a variable accordingly, one does not have to add a comment that explains the variable s nature and role. Accordingly , when you write a computer program, think about the other software developers who will have to work with the code, as readers of a book. In this sense, a comment is analogous to a footnote, which sometimes interrupts a reader s fluent reading. In book writing, however, there are cases when it is more logical to include endnotes and clarifications; there are cases in programming when comments should be added.

In addition, for the developer of the code, the addition of comments is not a good habit when it is applied in too many situations (as on each line of assembly code). Think about the habit to document in detail any small piece of code. If in later stages one wants to change one s code (see refactoring in Chapter 9), one would probably balk at the extra documentation work needed if changes are introduced into the code. Recording these thoughts may result in not improving the code.

Let us assume that this extra effort does not bother you and you do change the program when you find opportunities to improve it. In many cases, programmers forget to update the documentation in a way that corresponds to the updated code. Consequently, we may end up with documentation that does not fit the code that it documents. In such cases, think about the programmers who will have to work with code that is wrongly documented. Clearly, computer programs should be written in a way that enables future developers who will work with the code to perform their work easily.

Task  

Write two computer programs that execute the same task. The programming style of the first one requires the addition of many comments in order to understand it. The second computer program is written in a way that no comment (or almost no comments) is needed for its comprehension.

  1. Give the two programs to two programmers and ask them to explain the program they received. Observe and document the process through which both of them go. Draw your conclusions.

  2. Ask each of the two programmers to make the same modification in the program. Trace the change process in each case. What are your conclusions?

There are many specific programming guidelines related to programming style. Instead of just listing them all, we suggest using three mechanisms that may support the application of a communicative programming style: abstraction (see Chapter 11, Abstraction and Other Heuristics of Software ), refactoring (see Chapter 9), and simplicity. Naturally, additional mechanisms may be employed to achieve good programming style.

Abstraction

Abstraction was discussed in length in Chapter 11. Here we describe how it may be applied to programming style. We start by examining the names we assign to variables , functions, and any other object for which we can define a name in a computer program.

Task  

Why do people have names? Why do objects have names? What communication benefits do we get from using names?

Your answers to the preceding task may give you the right framework in which to think about the names you assign to functions, variables, and other identifiers in your programs. Names are given to identifiers to improve communication among programmers who work on the same code, including the one who writes the code. Inappropriate naming will not enable the person who develops the code to understand it a short period of time after the development is completed

The names we give to different things should be meaningful and reflect the essence of what we name in a mnemonic way. Abstraction is relevant here, as it enables us to forget about the details of how things are constructed or how they operate , and to encapsulate their essence in their name.

The desire to capture in one name the meaning of a thing leads to some applicable rules. Here are two examples:

  • Functions and procedures should be short enough so that they perform one task that can be reflected in their name.

  • One-character identifiers are not a good choice for naming objects. This is because such identifiers may not be informative (unless it is a convention to use such identifiers as in mathematical expressions, loop variables, and array indices).

One case that illustrates the idea of expressing the essence of things by giving them appropriate names is that of constants and enumerated types. Enumerated types allow us to declare a variable with a limited range of values, which can be numeric or any arbitrary strings. Accordingly, if you want a variable to store the days of the week, instead of storing the integer values of 1, 2, 3, . . . for Monday, Tuesday, Wednesday, it makes much more sense to give the enumerated values meaningful names.

Refactoring

The idea that computer programs are constructed in steps is clear. Here, we describe how programming style can be improved throughout a development process in which refactoring actions are intertwined (see Chapter 9).

Refactoring guides us not to stop working on a piece of code when we complete its first tested draft. Let us consider the book metaphor we used earlier. Authors do not stop working on a book as soon as they complete the first draft; rather, they keep improving it. For example, they look for better words to express the exact meaning of an idea they are trying to deliver. After these and many other small improvements, readers eventually get the feeling of reading a well-written book.

Another image taken from the world of book writing is the author, upset with what he has written throwing crumpled pages into the trash bin. The full-with-pages trashcan next to his table indicates that, instead of trying unsuccessfully to reformulate an idea he wants to communicate, he prefers to start writing from scratch on a white page. Similarly, there are cases in code developing in which it is not worth patching bad code, but rather it is better to rewrite it.

Task  

Suggest additional analogies between the process of book writing and the process of developing software systems in general and refactoring in particular. In what ways do these analogies help in understanding the nature of these two processes?

Simplicity

Let us continue with the metaphor of book writing and reading. It is reasonable to assume that when one reads a book, one would prefer that the book be written clearly, even if it delivers complicated ideas. This should also be the nature of the way in which software code is developed. The code should be simple, direct, and clear. Indeed, some programmers need reminding that clarity should not be sacrificed for efficiency. Since this efficiency is usually obtained by difficult and tricky expressions, in many cases the small gains that this efficiency adds are lost eventually in programmers misunderstandings and confusions.

Tasks  
  1. Suggest at least three guidelines that may help software engineers gain simplicity in the code they produce.

  2. How does XP (Chapter 2) treat the value of simplicity?

[1] According to the Confucian doctrine of Rectification of Names, such names must be meaningful. Confucius was the first programmer!




Human Aspects of Software Engineering
Human Aspects of Software Engineering (Charles River Media Computer Engineering)
ISBN: 1584503130
EAN: 2147483647
Year: 2004
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net