Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Good Programming Practices: A Style Guide for Writing Clear and Readable Code, Study notes of Logic

Guidelines for refactoring code, variable naming and access, readability, commenting and documentation, black-box testing, and const/reference in programming. It emphasizes the importance of consistency, simplicity, and avoiding redundancy and deep nesting. The document also discusses the use of commenting and documentation tools such as Sphinx, EpyDoc, and PythonDoc.

What you will learn

  • What is the importance of commenting and documentation?
  • What are the recommended variable naming conventions?
  • How can I improve the readability of my code?
  • What are some best practices for code refactoring?
  • What is black-box testing and how can it be used?

Typology: Study notes

2021/2022

Uploaded on 09/27/2022

lilwayne
lilwayne ๐Ÿ‡ฌ๐Ÿ‡ง

4.1

(7)

243 documents

1 / 38

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Good Programming Practices
Andrew Showers, Salles Viana
ALAC
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26

Partial preview of the text

Download Good Programming Practices: A Style Guide for Writing Clear and Readable Code and more Study notes Logic in PDF only on Docsity!

Good Programming Practices

Andrew Showers, Salles Viana

ALAC

Overview

โ— Code Refactoring โ— Variable Naming and Access โ— Tips for Readability โ— Commenting and Documentation โ— Black-Box Testing โ— Const/Reference

Code Refactoring

โ— Rewriting code for clarity, not bug fixing. Similar to writing paper drafts

โ— Rewrites may include: โ—‹ Documentation / Comments โ—‹ Change in Flow โ—‹ Variable Naming Conventions โ—‹ Creation of Functions / Classes โ–  Simplification โ–  Eliminating Duplicate Code โ–  Re-usable

Variable Naming Conventions

โ— camelCase ballRadius โ— Underscore between words -> ball_radius at start (private/protected) -> _speed โ— Uppercase for constants GRAVITY โ— Capitalize first word for classes Person()

Avoid Redundant Labeling

VS

Eliminate redundancy in order to create more readable code

Avoid Deep Nesting

VS

Avoid Long Lines

โ— Too many operations per line is confusing to read

VS

One Statement per Line

VS

Strive for Simplicity (cont.)

Use list comprehensions, filter(), and map() where applicable

VS

VS

Strive for Simplicity (cont.)

Use enumerate to keep track of index and element values

VS

Commenting (cont.)

โ— Avoiding obvious comments

โ— When possible, rewrite the code so no comments are necessary

VS

Commenting (cont.)

โ€œAt the beginning of every routine, it is helpful to provide standard, boilerplate comments, indicating the routines purpose, assumptions, and limitations. A boilerplate comment should be a brief introduction to understand why the routine exists and what it can do." https://msdn.microsoft.com/en-us/library/aa260844(v=vs.60).aspx

Documentation

โ— Sphinx โ—‹ http://www.sphinx-doc.org/en/stable/index.html โ—‹ http://www.sphinx-doc.org/en/stable/ext/example_google.html

โ— EpyDoc โ—‹ http://epydoc.sourceforge.net

โ— PythonDoc โ—‹ http://effbot.org/zone/pythondoc.htm#syntax

Black-Box Testing

โ— Given a function, you know what the output should be for given inputs โ—‹ Select cases which cover all typically expected behavior โ—‹ Software can verify function still works by running these tests

โ— DocTest โ—‹ https://en.wikipedia.org/wiki/Doctest