However the field still needs a more precise comment

This preview shows page 8 - 10 out of 16 pages.

. However, the field still needs a more precise comment that describes it. A field should be CamelCase with with the first letter lowercase. Fields that are private (e.g. are not accessed outside of the instance methods) should begin with an underscore.Property Names Examples:size, xCoordinate, noLines A property looks like a field, but it is really a collection of accessor methods (getters, setters, and deleters) for manipulating a field. A property typically corresponds to a field, which is private. As such the property name should be the same as the field name, but without the leading underscore. Comments Python has two types of comments: single line comments (which start with a # sign) and docstrings (which are enclosed in triple quotes). The following is a general rule regarding commenting: Specifications are docstrings; all other comments are single line comments.Specification Style All specification comments, be they for a function, module, or class, follow the same format. They are a docstring enclosed in triple-quotes on either side. They should start with a simple description that can fit on exactly one line. This should be followed by a blank line, and then a more detailed description of the specification. For example, here is a detailed specification for the function draw_oval:
9draw_oval(x, y, w, h): """Draw an ellipse that fits within the rectangle given. The upper left corner of the rectange is at position (x,y), its width is w, and its height is h. Use the current color to draw the ellipse.""" Note that we do not go into detail about the parameters until after the blank line. The goal is to make a first line that is as descriptive, but short, as possible. Sometimes the first line of the specification is enough information. In that case, there is no need for the blank line, as shown in the example below: def time(s): """Return: copy of s with no leading or trailing whitespace""" Module Comments Module comments are extremely important for this course, particularly as they are typically the first thing that we read when we grade your assignments. Module comments should be the very first thing in any module (e.g. a .py file), and they are composed of two parts. The first part of a module comment should use single line comments over three lines. The very first line should be the name of the module. The second line should be the name of the author; please include your netid. Finally, the last line should be the date that the file was last modified. For example, here are the first three lines of a module called sample: # sample.py # # January 24, 2015 The second part of the module comment should be the module specification, presented as a docstring. This is the documentation that will display when you use the help()command on this module. It should obey the basic rules for specifications, namely a short single line, followed by a blank line and then a more detailed explanation. Here is an example of a module comment in full: # sample.py # # January 24, 2015 """Module to demonstrate basics of Python style This module does not do anything interesting when it is loaded

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture