4 ms·

Isn't it amazing that code can get to that point? I mean, even insanely complex things like space shuttles/stations are understandable. They're documented, comp

Isn't it amazing that code can get to that point? I mean, even insanely complex things like space shuttles/stations are understandable. They're documented, compartmentalized in functionality, and maintainable. If they need to build onto it or swap out some functionality, they can do it. It's pretty sad that we let some software turn into behemoths that don't accept change.

andrewflnr 11y ago
That physical artifacts only have 3 dimensions probably makes it more difficult to introduce the sort of interconnectedness that tends to make software artifacts harder to understand.
MichaelGG 11y ago
I'm working on some C code now... functions that span a thousand (or more!) lines. With all variables declared at the beginning, many having one letter names or being reused at various points. With lots of chunks of code repeated. Shit, one chunk of code writes out a whole XML format to a file. Then the whole thing is is copy and pasted to write the same XML format to a socket. To add to the incomprehensibility, add feature-hacks everywhere. "get_flag" just does "thing->flags[name]". But "set_flag"? Hah, that's about 500 lines long and has all sorts of secret logic. (Does your flag name have a '[' in it? Does it start with "from_" or "to_"? Then you get a special code branch!) And then, just to give you the finger, we'll sprinkle newlines everywhere, seemingly at random, just to make the formatting look bad. Oh, and there won't even be a line of documentation detailing which structs do what, or any general logic or guide at all. But that's OK because code is documentation. Enjoy figuring out the custom "XML preprocessor" invented because "XML is too limited". This project was started fresh because a previous one was "bad". If you don't have someone with a strong sense of aesthetics that can push back on feature hacks and cheap implementations good intentions quickly decay.
- danieltillett 11y ago
  I don’t mind large functions if they make sense. I have one (god) function that is around 900 lines long, but it is just a series of function calls in order that checks each call for errors. Keeping the code linear like this reflects the data flow and makes it easy for me to remember the call order.

andrewflnr 11y ago

That physical artifacts only have 3 dimensions probably makes it more difficult to introduce the sort of interconnectedness that tends to make software artifacts harder to understand.

MichaelGG 11y ago

I'm working on some C code now... functions that span a thousand (or more!) lines. With all variables declared at the beginning, many having one letter names or being reused at various points. With lots of chunks of code repeated. Shit, one chunk of code writes out a whole XML format to a file. Then the whole thing is is copy and pasted to write the same XML format to a socket. To add to the incomprehensibility, add feature-hacks everywhere. "get_flag" just does "thing->flags[name]". But "set_flag"? Hah, that's about 500 lines long and has all sorts of secret logic. (Does your flag name have a '[' in it? Does it start with "from_" or "to_"? Then you get a special code branch!) And then, just to give you the finger, we'll sprinkle newlines everywhere, seemingly at random, just to make the formatting look bad. Oh, and there won't even be a line of documentation detailing which structs do what, or any general logic or guide at all. But that's OK because code is documentation. Enjoy figuring out the custom "XML preprocessor" invented because "XML is too limited". This project was started fresh because a previous one was "bad". If you don't have someone with a strong sense of aesthetics that can push back on feature hacks and cheap implementations good intentions quickly decay.

danieltillett 11y ago
I don’t mind large functions if they make sense. I have one (god) function that is around 900 lines long, but it is just a series of function calls in order that checks each call for errors. Keeping the code linear like this reflects the data flow and makes it easy for me to remember the call order.