Steal The Code

Pre-flight check

What is “good” code and why should I care?

Code Design Part I

Code smells and Functions

Shred this code

Code Review

Code Design Part 2

Intro to Modules and Packages

Poor man’s testing interlude

Module Mechanics

Module Search Path

Object Oriented Interlude

Why classes and OO?

Classes -- Bags of data and behavior

Customizing Classes

Code Design Part 3

Modeling with Classes

Coding the Classes

Integrating the classes

Code review

OO Interlude 2

Inheritance

Composition et al.

Code Design - Final Thoughts

Testing and other good habits

How To Get Better

Steal The Code

Exercises and completed sample code are on Github:

Pre-flight check

If you plan to bring your own machine to class, please make sure to follow below steps before class.

Install below software:

Download and run this shell script (note, only works on Mac/Linux).

What is “good” code and why should I care?

Why are we here? To write better code.

Why do we care about better code?

What is bad code? Think about a time you’ve written code that made you itch. Why? Did it have bugs? Was it hard to read? Hard to change?  Bad code, or code that makes you itch, typically has one or more code smells. [Talks about code smells]

What is good code? There are lots of ways to define “good” code, which could include judgments about code structure, how idiomatic it is, its efficiency, test coverage and many other variables. But let’s start with a simple definition that is easy to aspire to as a goal when we’re programming: Good code is READABLE code!

You don’t need to be a master programmer to decide whether your code is readable. You can tell just by looking at it.

Code Design Part I

Code smells and Functions

Overview of the long, gnarly script and discuss specific code smells in this script.

Shred this code

Exercise - Students form groups and chop up script (on paper) into smaller functions.

Code Review

Students present their solutions and we discuss differences in implementation. Compare their versions to ours.

Code Design Part 2

Intro to Modules and Packages

Overview of modules as namespaces for packaging code (data and functions/classes) and packages as collections of modules (with an __init__.py file). Whiteboard how we might organize our function-based script into more meaningful modules such as scraper.py, parser.py, summarizer.py

Poor man’s testing interlude

Before we start shuffling around code, how can we be sure we don’t break what we already have? Testing is the ideal way to do this for many reasons. But for today, we’ll use a simple file diff tool to compare the output of earlier versions of our code to later versions. This way we can have more confidence we’re not breaking things as we change the code.

Module Mechanics

Module and package mechanics - Students individually follow along as we create below and experiment in python shell:

Module Search Path

A quick crash-course on the module search path in the course of wiring up the data summarization script to use our fancy new library code.

Object Oriented Interlude

Why classes and OO?

What are classes and why should we care?

At most basic level, just another way to minimize complexity by logically grouping data and behavior.

A few specific technical benefits:

Classes -- Bags of data and behavior

Customizing Classes

Python lets you pre-load objects with data upon creation, rather than having to manually assign attributes after the fact. This is done by defining a special method called __init__. Think of it as saying “create this class and initialize it with the following attributes before returning that instance to me.”

Code Design Part 3

Reset code to a clean state and copy over libs from elex3 as a starting point.

Modeling with Classes

Review current logic in parser.py and summary.py and draw up list of data attributes for new Candidate and Race classes (we can decide downstream if these should be data attibutes or methods)

Coding the Classes

Integrating the classes

Code review

Compare and contrast with final implementation. What other changes could we make to improve the quality of this code? For example, making a Parser class with methods such as _get_or_create_race method? What else?

OO Interlude 2

Inheritance

Composition et al.

A quick mention of composition, multiple inheritance and other object-oriented concepts we won’t get into but which students should be aware of for future exploration.

Code Design - Final Thoughts

Testing and other good habits

Intermediate 0.1 to 0.2

0.1 is writing code that’s properly structured and readable. The next step is gradually adopting best practices to make it easier to manage code, deploy programs, and foster collaboration.

Keep in mind this is a quick overview of a lot of tools and best practices. Don’t try to learn and apply them all at once. That’s a recipe for frustration. Adopt them organically over time, as you face new challenges. You’ll know when you need them.

How To Get Better