Course Standards

Introduction

Most organizations have specific guidelines or standards about how work is to be performed, completed, tested and submitted. This page describes the standards for SDEV 140. It covers standards for configuring your Python programs , how to comment code, and how your assignments should be named and submitted.

Program Naming

In some editors,such as (Notepad++), your code must be saved as a file before it can be executed and tested. So it may be helpful at that point to name it so it can be submitted for the assignment.

Programs should be named in the following format:

Notice that the filename contains NO spaces or hyphens, and that your lastname comes before your first name or initial. The file extension should be ".py". Both IDLE and Notepad++ work with .py files. (If your editor defaults to a different file extension and cannot save files using a .py extension, let the instructor know.)

Program Header

All programs should have a standard header with course, author, date, program name and purpose. The header is 4 lines (not 1, 2 or 3). It should contain the following information:

Notice that there is a space after the hash mark that starts each comment line. Date should be in ISO format (yyyy-MM-dd). Use single-line comments (starting with "#" for the header); do NOT use a mutli-line comment.

Variable Naming

Various coding languages use different conventions for things like variable naming. A convention is a commonly accepted way of doing something, such as naming files or variables in a coding language. Naming styles have their own names, such as camel case, Pascal case, kebob case and snake case. You can read more about these common naming styles here.

For this course, please use either snake case OR Pascal case. Once you decide which you prefer, be consistent and use it all the time. Do not use different naming styles in the same program. (The exception is that the Python convention for constants is UPPERCASE. More on that later.)

Comments

All programs should include comments, in addition to the header. Comments help the reader understand the purpose of the code ,without having to read through it in detail.

It is not necessary to comment every line. But comments should be provided for sections or groups of code that have a similar purpose.

Place most comments above the lines of code (not to the right). In most cases, leave a blank line above each comment.

There should be a single space between the comment mark (#) and the comment text.

Program Banner

The program must display a banner when your program runs so it shows a title or purpose, and your name or initials. Examples:

Advanced Standards M02 and after

These standards will be "enforced" starting in M02. In other words, points will be subtracted for each program where the standards are not met.

• do not use literals (except 0); use global variables instead
• constants (global variables) should be named in all uppercase
• comment space: place one space after the # character
• number formatting: if not otherwise specified, decimals should always be 2 places (.2f)
• do not automatically convert input values: more below

When prompting and accepting user input, do not automatically convert inputs into numbers when a number is requested. Do not code like this:

See the page on User Inputs for more information on correctly prompting users and handling user inputs.

Advanced Standards: M05 and after

These standards will be "enforced" starting in M05. In other words, points will be subtracted for each program where the standards are not met.

• The main program should not perform any significant work (processing). Except for printing the banner, all other work should be contained in functions (methods).
• Global variables should be minimized. Constants are the exception and should be global variables. Most other variables should be scoped locally in each method.
• Methods should be as short as practical, and should primarily perform a single task (SRP: single-responsibility principle)
• All user input should be validated (see do not automatically convert input values, above)

Standards for GUI Programs

These standards will be "enforced" starting in M06. In other words, points will be subtracted for each program where the standards are not met.

• Instead of a banner being display in the console, set the title of the main window to display your name or initials at the end of the title, such as "Temperature Converter (by DRM)"
• Global variables should be minimized. Constants are the exception and should be global variables. Most other variables should be scoped locally in each method.
• Assign meaningful names to UI elements such as labels, text boxes and buttons. Do not use meaningless names such as "label0"
• You may position elements on windows using x/y coordinates or the grid - whatever works
• While methods should be as short as practical, GUI methods can often be very long and involve lots of code to create and design UI elements - that is understood.
• All user input should be validated (see do not automatically convert input values, above)
• Label messages on the window are preferred to popup messages for errors, etc.