1926: Bad Code
Title text: "Oh my God, why did you scotch-tape a bunch of hammers together?" "It's ok! Nothing depends on this wall being destroyed efficiently."
This comic is the fourth in the Code Quality series:
- 1513: Code Quality
- 1695: Code Quality 2
- 1833: Code Quality 3
- 1926: Bad Code
- 2138: Wanna See the Code?
Ponytail has caught Cueball in the act of writing some messy code - code in the form of a spreadsheet formula, which in turn produces another program in a language called Haskell. Haskell is a purely functional programming language, a concept that has a debatably steep learning curve, which causes it to be somewhat obscure, as referenced in 1312: Haskell. It is explained that this code will, in turn, interpret more source code, specifically code written in HTML. Parsing HTML is notoriously tricky without a dedicated software library for several reasons, including frequent changes to web pages, a nested structure of tags and quotes that frustrates regular expressions, allowing new lines to be started almost anywhere, and different standards that are followed or not followed to varying degrees.
After Cueball excuses his bad code by stating that "nothing depends on this" (meaning that no other projects rely on this code being good to operate properly), Ponytail uses the analogy of breaking a non-load-bearing wall to ridicule Cueball's excuse. A load-bearing wall is a wall that plays a role in supporting the building. Damaging such a wall would threaten the structural integrity of the entire building, and could potentially cause a collapse. In contrast, walls that aren't load-bearing are designed only to separate spaces within the building, and do not contribute to keeping the building up. Damaging or destroying such walls wouldn't endanger the overall structure of the building. However, supporting the building is just one of the functions which could depend on having an intact wall, and non-load-bearing walls are still there for a purpose. Walls serve many other important purposes, from creating opaque and sound blocking barriers (desirable for privacy purposes, particularly for bedrooms and bathrooms), to containing and protecting water pipes and electrical wiring. Ponytail's analogy suggests that, even though poorly written-code wouldn't cause the entire program to fail, it's still not a good idea.
Immediately after, Ponytail appears to have realized that she's only inspired Cueball to go ahead and break the wall, instead of swaying him away from writing ugly code. If left unchecked, this will only end in tragedy. Hilarious, knee-slapping tragedy.
This is most likely a continuation of the Code Quality series, but it differs slightly. For one thing, all of the previous strips were named "Code Quality <number>", with the exception of the first, which was just named "Code Quality". Also note that, unlike the previous Code Quality strips, Ponytail does not start using similes like "This is like being in a house built by a child using nothing but a hatchet and a picture of a house". It's also the longest explanation of Cueball's code by Cueball himself.
The title text suggests that Cueball's approach to breaking the wall - scotch-taping a bunch of hammers together - is as good as his code, and his excuse is similar.
- [Cueball is at his desk in a swivel chair, using his computer. Ponytail walks towards him.]
- Ponytail: That's the ugliest mess of code I've ever seen! What on earth are you working on?
- [Cueball swivels his chair to face Ponytail in a frameless panel.]
- Cueball: It's nothing weird this time, I swear.
- Cueball: It just looks bad because it's a spreadsheet formula.
- [Cueball is facing his computer again.]
- Cueball: ...which assembles a Haskell function.
- Ponytail: Uhhh.
- Cueball: ...for parsing HTML.
- Ponytail: ...oh my God.
- [Ponytail is pointing away from the scene.]
- Cueball: It's ok! Nothing depends on this.
- Ponytail: That wall isn't load-bearing. Does that mean we can just throw hammers at it?
- Cueball: ...I mean...
- Ponytail: Wait. Crap.
add a comment! ⋅ add a topic (use sparingly)! ⋅ refresh comments!