JZN666

> Code with lots of microdependencies to perform really trivial tasks.

"trivial" measure highly relies on programmer's/developer's experience and knowledge. For first developer traversing a tree and applying some updates based on nodes conditions would be "trivial" so thee places all the code in one function. For second developer the same problem would not be such trivial, so thee creates two functions "fn listFromNodes<T, U>(t: Tree<T>, pred: (fn(e: T) -> bool), map: (fn(e: T) -> U)) -> List<U>" and "fn applyUpdates(updates List<Update>)".

> Uncommented code

Why comment a code that's mapped to problem trivially observably (ex. if it's code describing some GUI component with style fields and your task is change style of its part)? I prefer commenting code that contains complex logic (which is measured through code reviews, developers skills, calls etc.) and its effects aren't observed obviously.

> Commented-Out code (git exists for a reason)

Yes and no. Commented-out code is usually in-place saved draft of old code. If some bug is encountered with new code, you can comment-out new code and uncomment-out old code quickly to discover a bug in new code later. Git is less easy to accomplish this task.

> Inconsistent naming

Some rudiment not quickly refactored, may be involved. Example, I had a project when I had type "CardRef" which initially contained only a name (string) of card which was used as a reference for it. Then I decided to include some scores for a card to selecting cards smarter. I kept a name for type the same because it was used a lot in a project for related entities.

> Can you absorb or re-absorb what it is doing rapidly by looking it over for a few seconds?

No. Not only because code is essentially poorly structured, but also because I'm not fluent in subject behind a code. Example is operating systems: when I look in Linux's source code for example, I can't understand which problem is solved by each routine. But does that make Linux source code "poor structured"?

These properties can be inherited from model/organization itself except "difficult to understand for wrong reasons" and "doesn't work" perhaps. So that's why I point to "respecting to model", a more generic take imho.

> non-neccessary complexity with regards to given model (problem, tools)

This looks like one of my points: "non-neccessary complexity". Why using "echo" statements if PHP is already designed as procedural web-templating language? If it's not a function that dynamically renders template based on some params.

* and decomposing a function in smaller functions

But this gives very short set of possible function names (up to 20 characters length (?), more is not adequate for development). And even with this parse_str could be named something like "url_parse_query_params_from_str(str)".

> I see tons of functions named update_data and get_state and add_items in the business logic sections

Maybe they're bounded by some clear context like class or module which serves specific set of tasks? Writing in well designed context MyPartOfSystem things like MyPartOfSystemUpdateData is another smellish side of naming I think. Or writing just long names that are used only in very short context (ex. variable "drivingLicenseCard" instead of "e", "entry" in "drivingLicenseCards.every((drivingLicenseCard) => drivingLicenseCard && checkSomehow(drivingLicenseCard))").

If they're not bound, then we have another source of spaghetti monster.