Course Standards

RevisedL 2021-10-01

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.

Important

Assignments with files not named with the standard below WILL NOT BE GRADED. Most assignments are 10-15 points: points will be deducted for the following: bad header (2), bad banner or no banner(2), very few or no comments (1), See below for banner description.

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:

module_assignmentnumber_exercise#_lastname-firstnameorinitial.extension
such as
m01_assn1_ex2_marrerodavid.py
OR
m01_assn1_ex3_marrerodavid.py
OR
m01_assn2_ex1_drm.py (Initials are okay - just always use the same ones)

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

See Below for Standard Related to GUI Programs

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:

# course: sdev 140
# author: marrero, d
# date: 2020-12-15
# purpose: demonstrate how to code Python

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.

# calculate average
games = 3
total_score = 465
average = total_score / games

# display results
print("Average score:".average)

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:

My First Python Program by drm
Calculating Sales Tax by D. Marrero

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:

age=int(input('Please enter your age: '))
All user inputs are strings. Accept the input as a string and then convert it:
age_entry = input('Please enter your age: ')
# convert entry to desired data type
age = int(age_entry)

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.