In this Chapter, I presented the following main concepts:

• Coding Standards
  • Coding Standards are collections of Coding rules, guidelines, and best practices
• Comment
  • Comments are text notes added to a Program to provide explanatory information about the Source Code
• Types of Comments
  • Single Line Comment
  • Multi Line Comment
• Best Practices for Comments
  • Some of the Best Practices in Commenting Code are as follows
    • Comment your Code
      • i.e., when writing your Code, also Comment your Code
        • After completing the Coding (with proper Comments), again go through the entire Code (and Comments) and
        • Check the quality of Comments
      • Comments should be of high quality and self-explanatory
        • i.e., anyone can understand your Code without taking any help from you
      • Be consistent in the use of Commenting Style
        • i.e., Use only one Commenting Style in all the Comments
      • Before writing Comments of Code, your Comments should present the 
      • Copyright Information
      • Authorship Information
      • Main purpose of the Program
        • Comments should be short, simple and easy to understand
      • Comments should not mix up with the Code
• Software Documentation
  • Any written text, illustrations or video that describes a Software to its Users is called Software Documentation (or Program Documentation)
• Guidelines for Creating High Quality Software Documentation
  • To produce high quality Software Documentation some of the main guidelines are as follows
  • Software Documentation should be 
    • complete and correct
    • Software Documentation should be written from the 
      • point of view of the reader
    • Software Documentation should follow the 
      • industry standards
• Consistency
  • Consistency is defined as steadfast adherence to the same principles of Character over time
• PEP 8 – Official Coding Style Guide for Python
  • PEP stands for Python Enhancement Proposal
    • The PEP 8 is the Style Guide for Python Code and it mainly covers
      • Formatting
      • Comments
      • Naming Conventions
      • Indentation Style
    • In Computer Programming, an Indentation Style is a convention governing the indentation of blocks of Code to convey Program Structure
• Best Practices for Indentation
  • In the Previous Slides, I identified 11 Best Practices for Indentation, which are as follows
    • Best Practice 1
      • Leave a Blank Line before Starting a Comment
    • Best Practice 2
      • There should be a Single Space on Left and Right Side of a Variable / Constant / Operator in a Python Statement
    • Best Practice 3
      • In an if Python Statement, Python Statement(s) after if Condition should be Indented with 
        • 4 Spaces 
    • Best Practice 4
      • In an if-else Python Statement, Python Statement(s) after if Condition and else Python Statement should be Indented with 
        • 4 Spaces
    • Best Practice 5
      • In a loop Python Statement, Python Statement(s) after loop Python Statement, should be Indented with 
        • 4 Spaces
    • Best Practice 6
      • In a function Python Statement, Python Statement(s) after function Python Statement should be Indented with 
        • 4 Spaces
    • Best Practice 7
      • If a Python Statement is greater than 79 characters then 
        • Wrapping long lines inside parentheses, brackets and braces
    • Best Practice 8
      • Usage of blank spaces 
      • After Class Definition use double blank spaces
      • After Function / Method Definition use single blank space
    • Best Practice 9
      • In a Python Program, write one statement per line 
    • Best Practice 10
      • In an import Python Statements, each import Python Statement should be on a separate line
    • Best Practice 11
      • In a Python Statement, use proper White Spaces in expressions and statements 
        • Consistency in Naming Scheme
          • Set of rules for writing Identifiers and other entities in Source Code and Documentation of a Python Program is called Naming Scheme / Convention
• Best Practices for Naming Convention
  • In the Previous Slides, I identified 6 Best Practices for Naming Convention, which are as follows
    • Best Practice 1
      • Variable Name
      • Variable Name should be in lower case
      • Avoid using single character (x,y,z,l,i) variable name
      • Use snake case for variable names
      • User underscore to separate words in long variable names
      • Use expressive variable names
      • Avoid variable names that begin with a number
      • Avoid using Special Characters (@,!,#,$) in variable names
  • Best Practice 2
    • Constant Name
    • Constants are usually declared and assigned values within a module
    • The naming convention for constants is an aberration
    • Constant names should be all CAPITAL letters
  • Best Practice 3
    • Function Argument
      • If function argument name clashes with keyword use trailing underscore
    • Use meaningful names
    • The lowercase naming convention should be followed
  • Best Practice 4
    • Module Name
    • Prefer underscores for long module names
  • Best Practice 5
    • Package Name
    • Avoid underscores for package names
  • Best Practice 6
    • Argument of Instance Method
    • The first Argument of an Instance Method (the basic Class Method with no strings attached) should always be self 
    • This points to the Calling Object
  • Best Practice 7
    • Argument of Class Method
    • The first argument of a class method should always be cls This points to the class, not the object instance
  • Best Practice 8
    • Follow CapWord (or camelCase) naming convention. Just start each word with a capital letter and do not include underscores between words
    • PEP 8 suggests that you use CamelCase for class definitions
    • If a class contains a subclass with the same attribute name, consider adding double underscores to the class attribute
  • Best Practice 9
    • Exception Classes
    • Use the suffix Error for exception classes
  • Best Practice 10
    • Use of Underscore
      • Single Leading Underscore _var
        • Naming convention indicating name is meant for internal use. A hint for programmers and not enforced by programmers
      • Double Leading and Trailing Underscore __var
        • Triggers name mangling when used in class context. Enforced by the Python interpreter
      • Underscore _
        • Used as a name for temporary variables
• Data and Code Organization
  • File
    • A File is the basic storage unit in a Computer
  • Folder
    • A Folder (a.k.a. Directory) holds one or more Files
• Data and Code Organization 
  • Data and Code Organization refers to the systematic arrangement of Data and Code used in developing a Software
• Best Practices of Data and Code Organization 
  • In the Previous Slides, I identified 4 Best Practices for Data and Code Organization, which are as follows
    • Best Practice 1
      • Put One Project in One Directory / Folder 
      • Make separate Sub-directories / Sub-folders for
        • Data 
        • Code
        • Documentation
      • In Data Sub-directory / Sub-folder
      • Make Sub-sub-directories / Sub-sub-folders (If Needed)
      • In Code Sub-directory / Sub-folder
      • Make Sub-sub-directories / Sub-sub-folders (If Needed)
      • In Documentation Sub-directory / Sub-folder
      • Make Sub-sub-directories / Sub-sub-folders (If Needed)
  • Best Practice 2
    • Use Relative Paths
  • Best Practice 3
    • Use Version Control System 
  • Best Practice 4
    • Name of File / Folder should clearly reflect the content of the File / Folder
    • File / Folder Naming Scheme / Conventions 
    • Use Consistent Computer Readable Naming Conventions
    • Avoid spaces in file and dir names
    • Use dashes-to-separate-words (slugs)
    • Be Consistent When Naming Files – Use Lower Case/Upper Case
    • Use Meaningful (Expressive) File and Directory Names
    • Avoid special characters or spaces in a file name
    • Avoid using final in file name
    • Don’t Use Proprietary File Formats
    • Proprietary formats are formats that require a specific tool (and a specific license often) to open. Examples include Excel (.xls) or Word (.doc)
    • Write ReadMe files
    • A README file contains information about other files in a directory or archive of computer software.
    • A form of documentation, it is usually a simple plain text file called READ.ME , README
• Code Grouping
  • Code Grouping is defined as the process of grouping Code into blocks
• Best Practices for Code Grouping
  • Below I present Best Practices for Code Grouping
    • Best Practice 1
      • Each blocks of code should be separated with some spaces between them
• Exception
  • • An exception is an event, which occurs during the execution of a program that disrupts the normal flow of the program’s instructions
• Exception Handler 
  • An Exception Handler is a piece of Code that stipulates what a Program will do when an Exception occurs in a Program
• Exception Handling 
  • In Programming Languages, Exception Handling is defined as the mechanism of handling Exceptions (or Runtime Errors)
• Best Practices for Exception Handling
  • Below I present Best Practices for Indentation
    • Best Practice 1
      • Use multiple except Statements when the try block contains Python Statements that may throw different types of Exceptions
    • Best Practice 2
      • Use a generic except clause, which handles any type of Exception
        • i.e., except Exception:
    • Note
      • Exception can be used with alias name using
        • as Keyword
    • Best Practice 3
      • After except clause(s), you can include an else-Block 
      • Code in the else-Block executes if Code in the try Block does not raise an Exception
      • The else-Block is a good place for Code that does not need the try Block’s protection
  • Best Practice 4
    • Use finally Block for the piece of Code which should be executed in all situations