Simplifying Development with Automation and Consistency – Lab 6 Walkthrough

Welcome to the Lab 6 journey! This blog post covers everything I did to enhance the Code Complexity Pro project by integrating automation, setting up a consistent code style, and making it super easy for any contributor to dive in. Let's explore the tools I used, why I chose them, and how they improve our workflow!

📌 Goal: A Consistent, Automated Development Environment

When working on a project with multiple contributors, consistency is critical. Without a unified coding style and automated checks, code can become difficult to maintain and read. Lab 6 is all about establishing a consistent, automated environment using tools for:

• Code Formatting: Enforcing a consistent style across the codebase.
• Linting: Identifying coding issues early to ensure quality and readability.
• Automation: Simplifying repetitive tasks like formatting, testing, and installation.

Let's dive into how I set up each part and why it’s important!

🔍 Step 1: Choosing Black as Our Code Formatter

Why Black?
Black is an “uncompromising” code formatter for Python, meaning it enforces strict coding standards without much customization. This is a big plus since it keeps the codebase consistent without room for stylistic debates.

What We Did:

• Installed Black in my project to automate code formatting and ensure consistent styling.
• Configured Black to format code with an 88-character line length, which is ideal for readability and matches industry standards.

Result: Now, whenever we save our files, Black ensures they are formatted to match the project’s style, which helps us avoid formatting-related commits and reviews.

🔍 Step 2: Adding Flake8 as Our Linter

Why Flake8?
Flake8 is a popular linter that checks for PEP 8 compliance and other common Python coding issues. It identifies syntax errors, unused imports, and other problems that can make code error-prone or harder to read.

What We Did:

• Configured Flake8 to run automatically and check our code.
• Set up Flake8 to match Black’s line length (88 characters) to avoid conflicts.
• Ignored certain rules that overlap with Black’s formatting to streamline our setup.

Result: Flake8 helps us catch small issues before they become big problems, improving code quality while we work.

🔍 Step 3: Creating a .blackignore File

Why .blackignore?
The .blackignore file allows us to specify files and folders that we don’t want Black to format. This is useful for excluding version control folders, virtual environments, and other files that don’t require formatting.

What We Did:

• Created a .blackignore file in the root of the project and added directories to exclude from formatting, such as:

  # .blackignore
  .git/
  __pycache__/
  venv/
  .venv/
  build/
  dist/
  .vscode/

Result: Black now ignores these folders, focusing only on the source code we are actively developing, which speeds up formatting and keeps the output clean.

🔍 Step 4: Automating with a Makefile

Why a Makefile?
A Makefile is a convenient way to bundle common tasks into simple commands. Instead of running multiple commands manually, we can use make commands to format, lint, test, and install dependencies with ease.

What We Did:
We created a Makefile with the following commands:

format:
    black .

lint:
    flake8 .

test:
    pytest

install:
    pip install -r requirements.txt

• make format: Runs Black to format all code.
• make lint: Runs Flake8 to check for code issues.
• make test: Runs tests to ensure everything works.
• make install: Installs dependencies from requirements.txt.

Result: With this Makefile, contributors can easily follow project standards by using simple commands.

🔍 Step 5: Setting Up Editor Integration with .vscode/settings.json

Why Editor Integration?
Automating formatting and linting within the editor helps maintain code standards in real-time. When settings are applied universally in .vscode/settings.json, all contributors using VS Code get the same experience.

What We Did:

• Created a .vscode/settings.json file to enforce the same setup across contributors.
• Configured settings to automatically format with Black and lint with Flake8.

{
  "python.formatting.provider": "black",
  "editor.formatOnSave": true,
  "python.linting.flake8Enabled": true,
  "python.linting.enabled": true,
  "python.formatting.blackArgs": ["--line-length", "88"],
  "python.linting.flake8Args": ["--max-line-length=88", "--ignore=E203,E266,E501,W503"],
  "files.exclude": {
    "**/__pycache__": true,
    "**/.git": true,
    "**/.vscode": true,
    "**/venv": true
  }
}

Result: This setup ensures that formatting and linting happen automatically, so contributors don’t have to remember to run them manually.

🔍 Step 6: Adding a Git Pre-Commit Hook

Why a Pre-Commit Hook?
Pre-commit hooks automatically run checks before changes are committed. This ensures that any code added to the repository adheres to our formatting and linting rules.

What We Did:

• Installed pre-commit and set it up to run Black and Flake8 before each commit.

To set up pre-commit, we added a .pre-commit-config.yaml file with the following configuration:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/psf/black
    rev: 22.3.0  # Use the latest Black version
    hooks:
      - id: black
        args: ["--line-length", "88"]
  - repo: https://github.com/pycqa/flake8
    rev: 4.0.1  # Use the latest Flake8 version
    hooks:
      - id: flake8
        args: ["--max-line-length=88", "--ignore=E203,E266,E501,W503"]

After creating the config file, we ran:

pre-commit install

Result: Now, every time we make a commit, Black and Flake8 run automatically, preventing non-compliant code from being committed.

🔍 Step 7: Cleaning Up Commits with Git Rebase and Squash

Why Rebase and Squash?
When working on a feature branch, it’s easy to end up with multiple commits. Squashing commits into a single one makes the commit history cleaner, making it easier to review and track changes.

What We Did:

• Used git rebase -i to squash all commits on the lab6 branch into one.
• Merged the squashed commit into main and pushed it to GitHub.

Result: Our commit history is now clean, making it easy to track the single, consolidated change for Lab 6.

📘 Final Thoughts

In Lab 6, I set up a unified, automated workflow that enforces consistent formatting, catches errors early, and streamlines collaboration. Contributors can now easily follow project standards, making the codebase cleaner and easier to maintain.

I hope this setup will help keep Code Complexity Pro organized and welcoming to new contributors. Happy coding! 🚀