9 Bad Programming Habits We Secretly Love (And Why They Persist)

Good programming habits are a work quality every programmer should have, yet many developers display bad habits, especially those early in their careers.

We have all secretly broken programming rules, much like sneaking candy when Mom isn’t looking, and we often justify these habits despite knowing they are undesirable.

Bad code doesn’t usually cause immediate catastrophic failures, so it can continue to work as long as it compiles and ships, which often satisfies clients.

Sometimes breaking rules can even produce cleaner, faster, or simpler code, and skilled programmers may exploit rule violations to their advantage.

Below are nine coding habits that are officially discouraged but many programmers still use unconsciously.

Programming Habit No. 1: Using goto

The prohibition of goto dates back to the era before structured programming tools. Early programmers used line numbers for jumps, later replaced by string labels.

Critics argue that goto leads to "spaghetti code" that is hard to read and understand, a view famously championed by Edsger Dijkstra.

However, in some cases a well‑placed goto can simplify complex branching compared to deeply nested if‑else structures, and certain bugs like the "goto fail" SSL vulnerability illustrate the risks of careless use.

Programming Habit No. 2: Skipping Documentation

Some developers avoid writing documentation, relying on self‑documenting code such as descriptive function names (e.g., insertReservation, cancelReservation).

When code changes rapidly, documentation can become outdated and misleading, making concise, well‑named code more valuable than stale comments.

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

Strict style rules may force each statement onto its own line, but this can lead to excessive line counts and reduced readability.

Conversely, writing multiple statements on a single line can sometimes make logic more compact and easier to follow.

Programming Habit No. 4: Omitting Type Declarations

Historically, explicit type declarations helped catch errors early, but modern compilers can often infer types, allowing cleaner code without redundant type annotations.

Programming Habit No. 5: Flipping Between Types

Some programmers repeatedly convert values between strings and numbers, which is inefficient, yet occasional conversions may be necessary when interfacing with third‑party libraries that expect specific types.

Programming Habit No. 6: Writing Your Own Data Structures

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

Programming Habit No. 7: Breaking Loops Mid‑Stream

Rules that forbid break or return inside loops can lead to more complex code. For example:

while (i<a.length){
   ...
   if (test(a[i])) return a[i];
   ...
}

Enforcing a loop‑constant may require an extra boolean flag:

while (notFound && i<a.length){
   ...
   if (test(a[i])) notFound = false;
   ...
}

While this can improve self‑documentation, it also adds complexity.

Programming Habit No. 8: Using Short Variable Names

Single‑letter variables like i or x can be perfectly clear in tight scopes such as loops, aligning with the principle that every word in code should carry meaning.

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 a risky but sometimes useful shortcut.

These nine habits illustrate why programmers may cling to seemingly bad practices, though they should be used with caution.