CS100 Fall 1998 Notes on Java Programming Style David GriesA goal of CS100 is for you to learn to write programs that are not only correct but also understandable. These guidelinesshould help you toward that goal. We ask that you follow these guidelines when writing programs in this course. They willgive you a good basis for developing a style of your own as you become a more experienced programmer. This handout includes guidelines for Java constructs that will be covered later in the semester. Skim these sections now andread them more carefully later when the topics are discussed. Table of contentsReasons for following a disciplined programming style Conventions for names: package names, class names, method names, parameter names, field names, local-variablenames, accessor names, constant names Indentation Statement-comments Specification of methods (procedures and functions) Definitions of variables (field names, parameters, and local variables) Specifying classes Acknowledgements Reasons for following a disciplined programming styleYour computer program should be readable, because if it is not readable, the chances of it being correct are slim. Moreover,if your program is unreadable, it will be difficult and time-consuming to find and correct the errors in it. So, The major reason for using a disciplined style of programming is that it will save you time whenever you have to readyour program or debug it.Your program should be readable by others, not just you. Consider a program you will write in this course. If the grader hastrouble understanding it, they is not likely to give you bad a grade. The more understandable, the simpler your programappears to a grader, the better the grade they will be willing to give you. Outside this course, making programs readable by others becomes even more important. Most programs live a long time andrequire "maintenance" --changes to adapt to new and different requirements, upgrades in other software, new hardware, etc.And the author of the program is quite likely not going to be around when the maintenance is required; someone else mustread the program and understand it enough to update it successfully. Even the programs you write for yourself should be readable; if not, four weeks after finishing it you will not remember itenough to make changes simply. Thus, simply for your own sake and for the sake of others, it makes sense to develop programming habits that lendthemselves to writing readable, understandable, and correct, programs. Part of these habits concern simple, syntactical measures like indenting program parts properly and using a few conventionsfor names of variables, methods, etc. The more important part concerns recording enough information in comments for thereader to understand how a program is designed and why. A computer program is the result many design decisions. These decisions --why this variable was introduced, what thatfunction does, etc.-- are often not reflected in the final Java code, which consists of low-level, detailed declarations andstatements. However, the higher-level design must be understood if a programmer is to modify the program successfully.Trying to understand decisions that are not recorded in comments in the code is tedious, error-prone, and aggravating --but alltoo common. So, it will be to your advantage to instill in yourself some disciplined programming habits, right from the beginning, like Write a precise definition (in a comment) of a variable as you write its declaration Update the definition of the variable (the comment) when you decide to change its meaning Write a precise specification for a method (which says what it does) as you write the method’s heading --don’t waituntil after the method is completely written or until the program is debugged. Change the specification for a method whenever you make changes to the body of the method that make the body notfit the specification. Preparing all the comments after the program is finished is bad for three reasons: (0) the comments were not of use to youwhen developing and debugging the program, so you took more time than was necessary. (1) The comments are harder towrite after the program is finished, because it is difficult to remember the meaning of all the variables and methods. (2) It isquite likely that you won’t write the comments --even programmers with the best intentions don’t spend much time filling incomments after the fact, because there are too many other interesting things to do. You will find that writing good comments as you write a program will help you clarify your ideas and write better, correctcode sooner. If you can write down clearly what your program is doing you are more likely to have a good understanding ofthe problem and your program is more likely to be correct. Time spent on careful thinking and writing is more than repaid intime saved during testing and debugging. Return to table of contents Conventions for namesGood naming conventions can help you and any reader of a program understand the program easily; bad naming conventionsor no naming conventions can lead to confusion and misunderstanding. Some people advocate using very long names thatdefine what the named entity (a method, field, local variable, etc.) represents. However, in general, this is not feasible. Agood definition for an entity may require three lines of explanation or more ---how can you have such a long name? On theother hand, extremely short names --one or two characters long-- don’t help at all. Thus, some in-between measures have tobe adopted. There are contexts where a short name is best and contexts where a longer name is best. Remember that a name can rarely be used to give a complete, precise definition of the entity it names, and a completedefinition should always be given where the entity is defined. The people developing Java programs have developed some conventions for identifiers, which help one readily see what theidentifier represents (to some extent). You can see these conventions at work by looking at the classes in java.awt (AbstractWindow Toolkit). Below, we state the conventions, with a few additions. Package names: e.g.AnimalStory A package is a set of classes that have been grouped together. The name of a package is usually something thatidentifies its contents. Generally speaking, a package name should begin with a capital letter, and all succeeding wordsin the name should start with a capital letter.Class names: