⚠

Privacy Notice: When you sign in with GitHub, your quiz attempts are stored in Google Firebase so you can track your progress. This data is only accessible to the course instructor, is not otherwise shared, and will be deleted at the end of the semester. For earlier deletion, contact the instructor. Prefer to stay anonymous? Use guest mode or a GitHub account without your real name.

● Progress is being saved

02 Exercise: PEP 8 Before/After Analysis

Score: 0 / 14

Question Overview

Pending Correct Incorrect

Instructions

This quiz tests your ability to analyze PEP 8 improvements in real Python code. You will compare “Before” (non-compliant) and “After” (compliant) versions of code snippets and identify the specific differences, rules applied, and reasoning behind each change.

Topics covered:

Spacing around operators and after commas
Import organization (grouping, sorting, unused imports)
Naming conventions (PascalCase, snake_case, UPPER_CASE)
Compound statements vs. separate lines
Multi-line formatting for function calls
Git diff implications of code formatting

Tip: Read both code versions carefully before answering. Small differences like a single space or a line break count as distinct improvements.

Question1 Difference Analysis

How many PEP 8 improvements were made between the Before and After versions?

Before:

def calc(a,b):return a+b

After:

def calc(a, b):
    return a + b

Enter a number:

Question2 Rule Identification

Which PEP 8 rules were applied in the After version?

Before:

def calc(a,b):return a+b

After:

def calc(a, b):
    return a + b

Select ALL that apply:

Select all that apply:

A) Use spaces after commas in parameter lists B) Class names should use PascalCase C) Avoid multiple statements on one line (compound statements) D) Surround binary operators with spaces E) Imports should be on separate lines

Question3 Rule Identification

Which PEP 8 rules were applied in the After version of these imports?

Before:

import sys,os,json
from typing import List,Dict
import numpy as np

After:

import json
import os
import sys
from typing import Dict, List

import numpy as np

Select ALL that apply:

Select all that apply:

A) Imports should usually be on separate lines B) Imports should be grouped by type (standard library, third-party, local) C) Imports within each group should be alphabetically sorted D) Use spaces after commas E) Put a blank line between different import groups F) Always use 'from' imports instead of plain imports

Question4 Best Practices

Why is the blank line between import groups important?

import json
import os
import sys
from typing import Dict, List
                                 # <-- this blank line
import numpy as np

A) Python requires it or the code won't run B) It makes the file longer, which is always better C) It visually separates standard library imports from third-party imports, making dependencies immediately clear D) It improves the performance of the import system

Question5 Difference Analysis

How many PEP 8 improvements were made between the Before and After versions?

Before:

class dataProcessor:
    def __init__(self,items):
        self.items=items
        self.count=len(items)
    def Process(self): return [x*2 for x in self.items]

After:

class DataProcessor:
    def __init__(self, items):
        self.items = items
        self.count = len(items)

    def process(self):
        return [x * 2 for x in self.items]

Enter a number:

Question6 Rule Identification

Which PEP 8 naming convention rules were applied in the After version?

Before:

class dataProcessor:
    ...
    def Process(self): return [x*2 for x in self.items]

After:

class DataProcessor:
    ...
    def process(self):
        return [x * 2 for x in self.items]

Select ALL that apply:

Select all that apply:

A) Class names should use PascalCase (CapWords convention) B) Method names should use snake_case (lowercase with underscores) C) Constants should use UPPER_CASE D) Module names should use PascalCase

Question7 Rule Identification

Which PEP 8 rules were applied in the After version?

Before:

camera={'x':0,'y':2.0,'z':1.5}
max_distance=100
default_threshold=0.5

After:

camera = {'x': 0, 'y': 2.0, 'z': 1.5}
MAX_DISTANCE = 100
DEFAULT_THRESHOLD = 0.5

Select ALL that apply:

Select all that apply:

A) Spaces around the assignment operator (=) B) Spaces after colons in dictionaries C) Constants should use UPPER_CASE naming D) Dictionary keys should use double quotes instead of single quotes E) Variable names should start with an underscore

Question8 Best Practices

Why were max_distance and default_threshold renamed to MAX_DISTANCE and DEFAULT_THRESHOLD?

A) Python requires constants to be uppercase or the code won't compile B) UPPER_CASE is easier to type than snake_case C) UPPER_CASE signals to other developers that these are constants that should not be modified during program execution D) Uppercase variable names run faster in Python's interpreter

Question9 Difference Analysis

How many PEP 8 improvements were made between the Before and After versions?

Before:

def process(data,threshold=10,debug=False):
    result=[]
    for item in data:
        if item>threshold:result.append(item*2)
    if debug:print(f"Processed {len(result)} items")
    return result

After:

def process(data, threshold=10, debug=False):
    result = []
    for item in data:
        if item > threshold:
            result.append(item * 2)
    if debug:
        print(f"Processed {len(result)} items")
    return result

Enter a number:

Question10 Best Practices

Why is breaking compound statements into separate lines important for debugging?

Before (compound):

if item>threshold:result.append(item*2)

After (separate lines):

if item > threshold:
    result.append(item * 2)

A) Separate lines make the code run faster because the interpreter can optimize each line independently B) You can set breakpoints on specific lines, stack traces show the exact line of failure, and it is easy to add logging or extra logic C) Python's debugger cannot parse compound statements at all D) Separate lines reduce memory usage because Python loads one line at a time

Question11 Difference Analysis

How many PEP 8 improvements were made between the Before and After versions?

Before:

from dash import Dash,html,dcc
import plotly.graph_objects as go
import numpy as np
import sys

def create_visualization(x_data,y_data,title="Plot"):
    fig=go.Figure()
    fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))
    fig.update_layout(title=title,xaxis_title="X",yaxis_title="Y")
    return fig

APP_title="Road Profile Viewer"

After:

from dash import Dash, dcc, html
import numpy as np
import plotly.graph_objects as go

def create_visualization(x_data, y_data, title="Plot"):
    fig = go.Figure()
    fig.add_trace(go.Scatter(
        x=x_data,
        y=y_data,
        mode='lines',
        name='Data'
    ))
    fig.update_layout(
        title=title,
        xaxis_title="X",
        yaxis_title="Y"
    )
    return fig

APP_TITLE = "Road Profile Viewer"

Enter a number:

Question12 Rule Identification

Which categories of PEP 8 rules were applied in the real-world example?

Before:

from dash import Dash,html,dcc
import plotly.graph_objects as go
import numpy as np
import sys

def create_visualization(x_data,y_data,title="Plot"):
    fig=go.Figure()
    fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))
    fig.update_layout(title=title,xaxis_title="X",yaxis_title="Y")
    return fig

APP_title="Road Profile Viewer"

Select ALL categories that apply:

Select all that apply:

A) Import organization (grouping, sorting, removing unused) B) Spacing around operators and after commas C) Multi-line formatting for long function calls D) Constant naming conventions (UPPER_CASE) E) Class naming conventions (PascalCase) F) Adding type hints to all parameters

Question13 Best Practices

Why is multi-line formatting preferred for function calls with many arguments?

Before (single line):

fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))

After (multi-line):

fig.add_trace(go.Scatter(
    x=x_data,
    y=y_data,
    mode='lines',
    name='Data'
))

A) Multi-line code executes faster because Python can parallelize each line B) Each argument is clearly visible, easy to add or remove, and produces cleaner git diffs when a single parameter changes C) PEP 8 requires all function calls to use multi-line formatting regardless of length D) Single-line function calls cause syntax errors when there are more than 3 arguments

Question14 Best Practices

A teammate changes mode='lines' to mode='markers' in a function call. Which formatting style produces a cleaner git diff?

Style A (single-line):

fig.add_trace(go.Scatter(x=x_data, y=y_data, mode='lines', name='Data'))

Style B (multi-line):

fig.add_trace(go.Scatter(
    x=x_data,
    y=y_data,
    mode='lines',
    name='Data'
))

A) Style A (single-line), because the diff shows fewer total lines changed B) Style B (multi-line), because the diff highlights only the changed parameter without touching the rest of the line C) Both produce identical diffs since the same amount of code changed D) Neither style affects git diffs because git tracks characters, not lines

02 Exercise: PEP 8 Before/After Analysis

Instructions

Quiz Complete!