10 So-Called Bad Programming Habits Developers Aren’t Ready to Give Up
We all have a penchant for bending or even breaking rules, whether it’s cruising slightly over the speed limit or letting the parking meter run out. In programming, this rebellious streak manifests as habits that defy conventional wisdom, yet many developers secretly cherish these so-called “bad” practices. Unlike the rigid rules that govern machine operations—rules enforced with exactitude by silicon gates—programmers often find their own set of rules more flexible and subject to reinterpretation.
Coding is fundamentally about adhering to rules, especially when it comes to machine instructions. These rules must be followed meticulously to ensure that the code performs correctly and efficiently. However, the rules that govern human behavior in coding—such as style guidelines and best practices—are more prone to personal interpretation. These rules are designed to make code more readable, maintainable, and consistent, but often, they are bent or ignored in the name of expedience or personal preference.
The real question is whether breaking our own programming rules is a beneficial practice or a dangerous precedent. After all, some rules may be outdated, originating from a different era or based on half-baked notions. Others might have seemed sensible at one time but now appear as mere habits rather than essential practices. Despite their drawbacks, certain habits persist because they offer practical benefits or align with personal coding styles.
Several years ago, I identified some of these endearing bad habits in programming. Today, let’s delve into ten more notorious programming habits that developers love, despite their apparent flaws:
- Coding without comments: Many developers skip comments, believing that their code should be self-explanatory. While this can make the code leaner, it often leads to confusion for others (and future you) who need to understand the logic behind the code.
- Slow code: Embracing slower, more straightforward code can be an act of rebellion against optimization mania. Developers might prioritize readability and ease of maintenance over performance, valuing simplicity even if it comes at a cost.
- Rambly code: Some programmers let their code meander, avoiding strict adherence to concise, modular practices. This approach can lead to less predictable but often more creatively expressive solutions.
- Ye olde code: Sticking with legacy code and practices—despite advancements in technology—can be a form of nostalgic resistance. Developers might favor older methods that they are comfortable with, even if newer techniques promise better performance.
- Roll-your-own code: Rather than using established libraries or frameworks, some developers prefer to write their own solutions from scratch. This habit can foster deep understanding and customization but also risks reinventing the wheel.
- Optimizing too early: Early optimization is a common habit among developers who want to preemptively enhance performance. While this can lead to more efficient code, it often results in overcomplicated solutions that address problems that may not yet exist.
- Carelessness: A laid-back approach to code quality, including minimal error handling and lack of validation, can sometimes lead to quicker results. This carelessness, though risky, can be a way to get things done faster, albeit with potential long-term issues.
- Inconsistency: Flouting coding standards and practices in favor of personal preferences can result in a codebase with varied styles. While this can make the code less uniform, it might reflect the individual developer’s unique problem-solving approach.
- Chasing bells and whistles: Focusing on adding unnecessary features or flashy elements can divert attention from core functionalities. Developers often indulge in these additions, driven by a desire to explore and experiment, even if they aren’t essential.
- Breaking the rules: Embracing and intentionally violating established programming conventions can be a way of challenging the status quo. This habit often involves pushing boundaries and discovering new methods, even if it means stepping outside of conventional practices.
These habits, while not always ideal, highlight the human element of programming—a blend of creativity, preference, and sometimes rebelliousness. Embracing these quirks can lead to unique and innovative solutions, proving that even bad habits can have their own form of value.