Ask HN: What's the largest amount of bad code you have ever seen work?

Post by maxxxxx » Wed, Nov 14, 2018, 5:40 AM UTC

siruncledrew wrote: post #149

wcarss wrote: post #10

Years ago as an intern at Microsoft, I had code go into the Excel, PowerPoint, Word, Outlook, and shared Office code. Excel is an incomprehensible maze of #defines and macros, PowerPoint is a Golden Temple of overly-object-oriented insanity, and Word is just so old and brittle you'd expect it to turn to dust by committing. There are "don't touch this!"-like messages left near the main loop _since roughly 1990_. I had…

Maybe in the year 2050 some future intern/employee will be adding to the Office code and wonder about the "Don't touch this" code relics of the past that someone from long ago left for future generations.

Post by PavlovsCat » Wed, Nov 14, 2018, 5:42 AM UTC

d0m wrote: post #102

PavlovsCat wrote: post #64

My own CMS. Here's the function signature of the heart of it, which depending on circumstance may call itself recursively. function a_nodes_list_trees( $site_url, $base_url, $mode, $site_id, $max_subtree_depth, $nlevels, $node_id = 0, $tree_id = 0, $nleft = 0, $nright = 0, $nlevel = 0, $current_subtree_depth = 0, $flags = 0, $order = 'tree', $inline = false, /* needed when loading stuff via ajax*/ $skipped_types = []…

An easy refactor for your function is to use a "Builder" for your params, i.e.: options = NodeBuilder .author({ min: 2 }) .flag({ .. }) .pagitation({ .. }) function a_nodes_list_trees(options) { ... } Because in the end, if your function is fast and working correctly, it's fine even though it's a little bit messy. The problem is more all the code calling this function and having to pass dozens of params in the right…

Post by PavlovsCat » Wed, Nov 14, 2018, 5:48 AM UTC

pmarreck wrote: post #121

PavlovsCat wrote: post #64

My own CMS. Here's the function signature of the heart of it, which depending on circumstance may call itself recursively. function a_nodes_list_trees( $site_url, $base_url, $mode, $site_id, $max_subtree_depth, $nlevels, $node_id = 0, $tree_id = 0, $nleft = 0, $nright = 0, $nlevel = 0, $current_subtree_depth = 0, $flags = 0, $order = 'tree', $inline = false, /* needed when loading stuff via ajax*/ $skipped_types = []…

You're benefitting from an accurate mental model of this code (since you wrote it and work on it) and as soon as someone else has to work on this thing they are going to curse you. So it might be job security but it's also vulnerable to the hit-by-a-bus problem

Post by flukus » Wed, Nov 14, 2018, 5:52 AM UTC

jjeaff wrote: post #134

technix32 wrote: post #116

Earlier quoted context omitted.

This is a complete fallacy IMO. The time is 10 fold down the line when people are attempting to reverse engineer in order to maintain it.

Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly.

Post by yjftsjthsd-h » Wed, Nov 14, 2018, 5:58 AM UTC

deanmoriarty wrote: post #120

pmarreck wrote: post #101

Here's a metaquestion: Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage? I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hopi…

Linux kernel is massive and has been around for decades now and it’s probably millions of lines. It certainly has a lot of cognitive overhead since you need to always keep in mind the context in which the code you are writing will be running (to reason about concurrency etc.), but it’s relatively easy to understand and well written.