Ask HN: What's your biggest code smell?

The thing where flags, arguments, settings, options produce a conflict and the wrong behavior.

Ex: Dropdown-Menü for <select> <a>, <b>, or <c> combined with a checkbox for [all] that grays out the Dropdown but doesn’t change the option to [all] if <a-c> is selected before checking the box.

See <update manually>, <install automatically>, <download only>, or [no updates].

Same for multiple handles trying to negotiate system settings and app settings for a database with api calls like the photos app, notoriously.

Blatantly obvious bugs and well-known bad practices every few lines. You can't ever trust the code without rewriting it function by function.

Second place: All territory, no map.

Is there a design document? An architecture description? Comments that tell why, not just what? If a new person starts work on the code, do they have to step through it to figure out what's going on, or is there a map, signposts, and a guidebook?

Spaghetti. I know that people like mentioning inheritance, factory and template hells, but trust me. If you've seen spaghetti, where there is no reusability in the entire codebase, then you know.

There is a reason we like to think of objects as something that when constructed is valid and reusable, regardless of language. Even most decent C code looks like conservative object-oriented programming.

The level of abstraction doesn't change when stepping down through levels of indirection.

ManagedHttpService calls HttpService which calls HttpManager which calls HttpClient. None of the above actually speaks 'http'; all of the actual http code lives in an apache dependency referred to inside HttpClient.

Duplicated code. If you want to change that block, you have to change it evrey place it occurs. It should be extracted into a common function.

No comments, few comments, irrelevant and/or unhelpful comments, confusing comments.

Heavily-nested code with tons of conditional logic branches & no code comments.

"Biggest" is hard to quantify, but "most common" for sure is the combination of repeatedly executing the same expression (versus assigning it to a variable and using that reference multiple times) which often goes along with my red-alert "what is wrong with you?" of using one thing and logging another

    doAwesome(thing.otherThing().somethingElse());
    LOGGER.info("I used {}", thing.otherThing().somethingElse());

    // or its friend, this horseshit

    if (thing.otherThing().somethingElse() != null) {
       doSomething(thing.otherThing().somethingElse());
    } else {
       LOGGER.warn("somethingElse was null "+thing.otherThing());
    }

(we will ignore the Law of Demeter for the purposes of this rant, since in my professional experience that ship has sailed)