Are You Looking for ICT112 Doc Style for Documentation and Coding Style in 2019? This is a basic guide for documentation and coding style for ICT112 2019, note that it is based on the Official Python Style. Get case study answers to questions in ICT112 Pythong Programming Assignment Help, ICT112 Doc Style or Code Style from programming experts online in Australia, UK and USA.

 

ICT112 Code Style

This is a basic guide for documentation and coding style for ICT112 2019, note that it is based on the Official Python Style: PEP8 (https://pep8.org/#naming- conventions) modified to include Hungarian notation to assist beginner programmers to conceptualize scope and types. For more information on Hungarian notation see http://codevba.com/help/VB_naming_conventions.htm#.XJMDSFMzZTY

Outside of the variable naming (which is as above), a good references are: https://realpython.com/python-pep8/ and https://realpython.com/documenting- python-code/

NAMING

• Useful names are:
  • Descriptive
  • Not too long
  • Not “STEVE!”
• Package names: alllowercase
• Module names: alllowercase or all_lower_case
• Class names: CapName (sometimes called CamelCase)
• Function names: words_separated_by_an_underscore
• Variable names: also words_separated_by_an_underscore

SCOPE

• Internal/non-public: _variable_name or _function_name
• Intended variable Scope:
  • Class level: _cls_var
  • Module level: _mod_var
  • Global g_global_var
• Constants: g_c_type_GLOBAL_CONSTANT or m_c_type_MODULE_CONSTANT

• Types are important: (Not standard Python Style but helps readability)
  • Integer: int_number_var
  • Decimal/Double: dbl_decimal_var
  • String: str_string_var
  • List: lst_list_var
  • Dictionary: dict_dictionary_var
  • File: file_file_var

COMMENTS

All files must have comments at the start of the file, above every module/class, above every method, and throughout code as needed for clarity. These comments conform to standard PEP8 – https://realpython.com/python-pep8/

File comments:

• Must name file, author, and purpose of file.
• If file is executable, must include example usage.

For example:

  author   = “Erica Mealy, Mark Utting, and Adriano da Silva Marinho”

  version   = “0.0.1”

  email = “emm042@student.usc.edu.au”

“””Example style docstrings.

• This module demonstrates documentation. Docstrings may extend over multiple lines Sections are created with a section header and a colon followed by a block of indented text.

Example:

• Examples can be given using either the “Example“ or “Examples“ sections. Sections support any reStructuredText formatting, including literal blocks::

$ python example_google.py

Attributes:

• module_level_variable1 (int): Module level variables may be documented in either the “Attributes“ section of the module docstring, or in an inline docstring immediately following the variable.

“””

Function comments

Every function should have a comment that succinctly explains what it does, the parameter/s it expects (including type) and the return value.

For example:

def ball_height(vel0, time): “””Calculates the height of a ball.

:param vel0: upward initial speed (metres/sec)

:param time: current time in seconds.

:returns: the height of the ball in metres. “””

up = vel0*time

down = 0.5 * 9.8 * time**2

return up – down

GENERAL FORMATTING

• Indentation is important – ensure you indenting is correct, especially for if/else statements where the else is a number of lines below the if statement.

• Lines should be kept to a reasonable length – PEP8 says 80 characters wide
  • Continue lines sensibly see https://realpython.com/python- pep8/#maximum-line-length-and-line-breaking

• Use spaces NOT tabs (note that Jupyter will change uses of the tab key INTO spaces for you)

• Include spaces around binary operators – e.g. 1 + 2, NOT 1+2

• Don’t include space before OR after :,(,[, – e.g.
  • def fn_name(param):
    • NOT def fn_name(param) :
    • NOT def fn_name (param):
    • NOT def fn_name( param ):
  • list [3]
    • NOT list [3]
    • NOT list[ 3 ]

• Use Vertical white space (aka line breaks) to help separate classes and functions from other code.
• Never use l (lower case L), O (capital o) or I (capital i) as variable names as they can easily be mistaken for 1s and 0s