0% found this document useful (0 votes)
41 views

Python Coding

The document outlines coding standards for Python files, including: 1. File level comments at the top of each file with metadata like team ID, authors, filename, functions, and global variables. 2. Function level comments before each function with its name, inputs/outputs, logic, and example call. 3. Descriptive variable names and optional comments explaining variables. 4. Implementation comments in complex code sections to describe what the code is doing. The standards are illustrated with an example Fibonacci series program.

Uploaded by

dfkoejfi
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
41 views

Python Coding

The document outlines coding standards for Python files, including: 1. File level comments at the top of each file with metadata like team ID, authors, filename, functions, and global variables. 2. Function level comments before each function with its name, inputs/outputs, logic, and example call. 3. Descriptive variable names and optional comments explaining variables. 4. Implementation comments in complex code sections to describe what the code is doing. The standards are illustrated with an example Fibonacci series program.

Uploaded by

dfkoejfi
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Coding Standard - For Python

● The following documentation and comment styles are to be used for the
code submitted by the teams.
● Replace all the <Description> tags from the comments below to add
appropriate content for your application.

1. File Level Comments

Each user’s code file should start with File Level comments in the format as
follows:

```
* Team Id : <Team Id>
* Author List : <Name of the team members who worked on this function
* (Comma separated e.g. Name1, Name2)>
* Filename: <Filename>
* Theme: <Theme name -- Specific to eYRC / eYRCPlus >
* Functions: <Comma separated list of Functions defined in this file>
* Global Variables: <List of global variables defined in this file, none if no global
* variables>
```

2. Function Level Comments

Each function should have the following comment section before it:

```
* Function Name: <Function Name>
* Input: < Inputs (or Parameters) list with description if any>
* Output: < Return value with description if any>
* Logic: <Description of the function performed and the logic used
* in the function>
* Example Call: <Example of how to call this function>
```

3. Variable Comments
In general the variable/function names should be descriptive enough to
give a good idea of what the variable is used for., For example, variable
names like black_line_threshold_value', 'left_motor_turn_right' are
preferable and makes your code readable. Variable names like 'a', 'b' and
'temp' are not acceptable variable names.

In some cases, variable names might require some description for which
the following format can be used:

# Variable Name: Description of the variable and the range of expected values of the variable.

4. Implementation Comments

In your implementation/actual code, you should have comments in tricky,


non‐ obvious, interesting, or important parts of the code.

The comments can be of the format as below:

# Describe what the code below is doing

An Illustrative Example:

We provide sample comments in a rudimentary program that outputs the


Fibonacci Series (For more information on Fibonacci Series visit:
http://en.wikipedia.org/wiki/Fibonacci_number). Please note that this is not
the complete and perfect example of generating Fibonacci Numbers but
acts as a simple way to illustrate the coding style and comments explained
above.
import os, sys
“Any fool can write code that a computer can understand. Good programmers
write code that humans can understand.” - Martin Fowler
---------------------------------------------------------------------------------------------------------------------
“Programs must be written for people to read, and only incidentally for machines
to execute.” - Hal Abelson & Gerald Jay Sussman
---------------------------------------------------------------------------------------------------------------
“Always code as if the guy who ends up maintaining your code will be a violent
psychopath who knows where you live.” - Rick Osborne

You might also like