Refactoring From Messy to Idiomatic Writing code that works is only the first step. True software craftsmanship lies in making that code readable, maintainable, and idiomatic. In Python, we call this writing Pythonic code. Writing Pythonic code means using the language's built-in strengths rather than fighting against them. We want to avoid overengineering, reduce boilerplate, and write logic that feels natural. This guide steps through how to refactor a clunky, rigid fitness tracking script into clean, beautiful Python. We will replace unnecessary classes with clean functions, implement safe resource management, and apply modern standard library tools. Prerequisites and Toolkit To follow this tutorial, you should understand basic Python syntax, functions, and file operations. We will use several built-in modules to clean up our code: * dataclasses: Simplifies class creation for data storage. * pathlib: Provides an object-oriented approach to handling file paths. * logging: Offers a robust way to track events instead of using print statements. The Code Walkthrough Let us look at how to structure our program. We start by removing a class that has no state and replacing it with focused functions. Then, we use a data class to structure our inputs and an iterator to stream data safely. ```python from dataclasses import dataclass, field from datetime import datetime from collections.abc import Iterator from pathlib import Path import logging Centralize paths as constants using Path objects FOOD_FILE = Path("food.csv") ACTIVITY_FILE = Path("activities.csv") Setup logging configuration logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s" ) def today() -> str: return datetime.now().strftime("%Y-%m-%d") @dataclass class Entry: description: str calories: int date: str = field(default_factory=today) def append_entry(file_path: Path, entry: Entry) -> None: # Using a context manager ensures safe file closing with open(file_path, "a") as f: f.write(f"{entry.date},{entry.description},{entry.calories}\n") logging.info(f"Appended entry: {entry.description} ({entry.calories} cal)") def read_entries(file_path: Path) -> Iterator[Entry]: # Easier to Ask Forgiveness than Permission (EAFP) try: with open(file_path, "r") as f: for line in f: parts = line.strip().split(",") if len(parts) == 3: yield Entry(parts[1], int(parts[2]), parts[0]) except FileNotFoundError: logging.warning(f"{file_path} not found. Starting fresh.") def run_day_summary(date: str) -> None: food_list = list(read_entries(FOOD_FILE)) activity_list = list(read_entries(ACTIVITY_FILE)) # List comprehensions filter and aggregate data cleanly food_total = sum(e.calories for e in food_list if e.date == date) activity_total = sum(e.calories for e in activity_list if e.date == date) net_calories = food_total - activity_total print(f"--- Summary for {date} ---") print(f"Food intake: {food_total} calories") print(f"Activity burn: {activity_total} calories") print(f"Net: {net_calories} calories") def main() -> None: # Clear entry point avoiding global namespace pollution banana = Entry(description="banana", calories=100) append_entry(FOOD_FILE, banana) running = Entry(description="running", calories=300) append_entry(ACTIVITY_FILE, running) run_day_summary(today()) if __name__ == "__main__": main() ``` This refactored script is modular. We replaced manual file closing with context managers. We replaced repetitive manual parsing with a reusable generator function that yields clean data objects. Syntax and Best Practices This refactoring highlights several Pythonic paradigms. First, we favor **EAFP** (Easier to Ask Forgiveness than Permission) over **LBYL** (Look Before You Leap). Instead of checking if a file exists before opening it, we try to read it and catch the `FileNotFoundError`. Second, we use **default factories** in our data class. If you write `date: str = today()`, Python evaluates that default value exactly once when it loads the module. Every entry created thereafter gets that same frozen timestamp. By using `default_factory=today`, Python executes our function every single time we instantiate a new `Entry`. Finally, we use an **Iterator** via the `yield` keyword. Yielding records one by one keeps memory consumption minimal, even when handling large files. Tips and Pitfalls Avoid creating classes that do not hold state. If a class only contains a constructor and a few methods that do not modify `self`, delete the class. Write pure functions instead. Do not use print statements for operational tracking. Prints clutter standard output and make debugging difficult. Standardize on the built-in logging library to gain timestamps and severity levels automatically.
ArjanCodes
Companies
Jul 2022 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
Jul 2023 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
Jul 2024 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
Jan 2025 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
May 2025 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
Nov 2025 • 1 videos
High activity month for ArjanCodes. ArjanCodes among the most active voices, with 1 videos across 1 sources.
- Nov 7, 2025
- May 9, 2025
- Jan 10, 2025
- Jul 12, 2024
- Jul 7, 2023
The Evolution of a Developer Perspective When we look at the trajectory of a successful software project or a career, we often obsess over the end state. We see the 100,000 subscribers, the five million views, or the robust production application. But the reality of growth is far more chaotic and experimental. My own journey with ArjanCodes didn't begin as a Python channel. It started as a reflection on the mistakes I made while running a startup. I wanted to talk about picking the wrong libraries, choosing the wrong platforms, and making poor architectural decisions. The pivot to technical tutorials happened because the audience responded to the "how" and the "why" of code. It wasn't about being a Python guru; it was about the discipline of software design. I realized that while many people know the syntax of a language, fewer understand how to get from a problem description to something that actually makes sense in code. That process—the translation of logic into maintainable architecture—is the most interesting part of programming. It transcends specific frameworks or the flavor-of-the-month library. It’s about building systems that don't crumble under their own weight the moment you need to change a requirement. The Iteration Mindset in Code and Life One of the most frequent questions I get is about the production quality of my work. People want to know the "secret." There isn't one. The only principle that matters is iteration. In the startup world, we talk about it constantly, but we rarely apply it to our personal development or our coding practices with enough rigor. If you look at my videos from a year ago, I look like a green alien with terrible lighting. I didn't wait until I had a perfect studio to start; I started, noticed a problem, and refused to tolerate it. This is exactly how we should approach software development. You don't have to write perfect code on the first pass. In fact, if you try, you'll likely over-engineer a solution to a problem you don't fully understand yet. Instead, take small steps. Improve the lighting. Tweaking the microphone. Refactor that one function. This persistent, incremental improvement has incredible results over the long term. As Ray Dalio mentions in his book Principles, you must be perceptive enough to notice problems and adamant enough to fix them. Whether it’s a bug in your deployment pipeline or a bad shadow in a video frame, the process of fixing it is what builds expertise. The Paradigm Shift: Functional vs. Object-Oriented There is a long-standing tension in the industry between Object-Oriented Programming (OOP) and Functional Programming. For a long time, we were told that if you’re building "serious" business applications, you must use OOP. This is a rigid way of thinking. Python is unique because it supports both paradigms strongly, and I find myself moving more toward functional approaches every day. Functions often lead to shorter, more readable code because they require less boilerplate. However, classes still have a vital role in representing structured data. If you use Pydantic or data classes, you get validation and type safety that are harder to achieve with just dictionaries or tuples. My rule of thumb is simple: use classes for data and state, but use functions for behavior. If a method in a class starts getting too long, I split it out. I don't care about purity; I care about readability. You aren't marrying a paradigm. You are using tools to solve a problem. If the code is easy for another developer to understand six months from now, you’ve won. If you followed every design pattern but made the code unreadable, you’ve failed. Navigating the Framework Marriage Choosing a framework like Django or React is a major life event for your code. As Robert C. Martin points out, you are essentially marrying the framework. You have to follow its rules, its directory structures, and its philosophy. If you try to fight the stream, you’ll just end up with a mess. For example, if you're in Django, you should do things the "Django way." But that doesn't mean you should let the framework bleed into everything. You still need a layer of your own business logic that is independent. This is why I focus so much on Software Architecture. Whether you're using Node.js or Python, the principles of dependency injection and modularity remain the same. The goal is to make the framework a detail, not the entire story. This becomes critical when you look at deployment. Tools like Docker and Kubernetes have standardized how we think about infrastructure, but even there, simpler is often better. I find myself reaching for AWS Lambda or Google Cloud Run more often because they remove the burden of infrastructure management entirely. Education, Degrees, and the Job Market Is a Master's degree in Computer Science worth it? Years ago, I would have said yes without hesitation. Today, the answer is more nuanced. Universities are in a strange position. Computer science moves so fast that a four-year curriculum is often out of date by the time a student reaches their senior year. Academic environments are naturally geared toward theory, which is great for learning Mathematics, but less effective for learning how to deploy a microservice at scale. Furthermore, the grading system in traditional education can actually hinder learning. Research shows that once you grade someone, they stop being interested in the material and start being interested in the grade. My advice to anyone starting out is to treat your first job as your true education. Bootcamps are excellent for pivoting careers quickly, but if you already have the basics, nothing beats working on a real-world project. Developing your analytical skills—the ability to cut a problem into small pieces—is the only "advanced" skill that actually matters. Syntax is easy; logic is hard. The Motivation of the Lifelong Learner Staying motivated in this field isn't about chasing the highest salary or the trendiest language. It’s about intrinsic curiosity. I've been coding since I was 10 years old, starting on a Commodore 16. Even if I weren't doing this for a career, I’d still be doing it for fun. The beauty of teaching on YouTube is that it forces me to learn in the open. Every time I prepare a video on Infrastructure as Code or a specific library like Pulumi, I have to dive deep into the documentation. I have to defend my choices to a community of 100,000 people. This feedback loop keeps me sharp. It’s a reminder that we are all students. If you view yourself as a guru, you stop growing. If you view yourself as a learner, every critical comment is an opportunity to rethink your design and every new framework is a playground. Focus on the basics, iterate relentlessly, and keep your logic simple. That is the only path to becoming a pro.
Jul 29, 2022