9 Bad Programming Habits We Secretly Love

We have all secretly enjoyed breaking programming rules, just as we once sneaked candy when our mothers weren’t looking, even though such habits are officially condemned.

Even though poor coding practices may not cause immediate crashes, they often work and satisfy clients as long as the code compiles and runs.

Bad code isn’t as dangerous as a short circuit; it usually functions, and rules are merely guidelines, not strict mandates, though violating them can invite ridicule.

Sometimes breaking the rules can actually produce cleaner, faster, or simpler code, especially when clever developers know how to exploit the flexibility.

Below are nine coding habits that are widely criticized but many programmers still use unconsciously.

Programming Habit No. 1: Using goto

Historically, goto was used before structured programming tools existed, allowing jumps to line numbers or string labels.

Critics argue it creates "spaghetti code" that is hard to read, a view famously championed by Edsger Dijkstra.

However, in some cases a well‑placed goto can simplify complex switch statements compared to deeply nested if‑else blocks.

Security‑critical examples like the "goto fail" SSL bug show the risks, but careful use can improve clarity when alternatives are cumbersome.

Programming Habit No. 2: Avoiding Documentation

Some developers rely on self‑documenting code—meaningful function names like insertReservation or deleteAll —instead of verbose comments.

When code changes rapidly, documentation can become outdated and misleading, making concise, expressive code more valuable.

In such scenarios, well‑named code wins over stale comments.

Programming Habit No. 3: Writing Too Much Code on One Line

Strict style guides sometimes force every statement onto its own line, which can be tedious and inflate line counts.

Conversely, packing related statements together can make the logic more compact and easier to follow.

Programming Habit No. 4: Omitting Type Declarations

While explicit types help catch errors early, modern compilers can infer types, allowing developers to skip redundant declarations.

This can produce cleaner code, especially when the inferred type is obvious (e.g., i as an integer iterator).

Programming Habit No. 5: Swinging Between Types

Some programmers repeatedly convert data—string to int and back—leading to inefficiency, but occasional conversions may be justified when interfacing with third‑party libraries that expect specific types.

Re‑engineering code to eliminate all conversions can be costly; sometimes accepting the overhead is a pragmatic trade‑off.

Programming Habit No. 6: Writing Your Own Data Structures

Standard libraries provide well‑tested data structures, yet developers sometimes implement custom ones for performance or to avoid unnecessary features.

Custom structures can be faster and cleaner when the built‑in alternatives are ill‑suited.

Programming Habit No. 7: Breaking Loops Mid‑Stream

Some style rules forbid return or break inside loops, insisting on a constant loop condition.

This can lead to convoluted code, such as introducing a notFound boolean to control loop exit.

In practice, a well‑placed break or return often makes the logic clearer.

Programming Habit No. 8: Using Short Variable Names

While expressive, long variable names can be cumbersome; single‑letter names like i or j are widely understood as iterators.

When used judiciously, short names contribute to self‑documenting code.

Programming Habit No. 9: Redefining Operators and Functions

Some languages allow redefining constants or operators (e.g., assigning TRUE = FALSE in older Python versions), which can be risky but occasionally useful for rapid prototyping.

Such tricks should be used sparingly, as they can introduce subtle bugs.

These nine habits illustrate why developers sometimes flirt with rule‑breaking, but they also highlight the potential dangers of doing so.