Browse Source

Added rant on the best code

master
dirkson 5 months ago
parent
commit
6496e0f4fa
1 changed files with 57 additions and 0 deletions
  1. 57
    0
      src/bestcode.md

+ 57
- 0
src/bestcode.md View File

@@ -0,0 +1,57 @@
## The Best Code

Some code is better than other code. How do you figure out which one is which? I'm going to attempt to outline the basic method I use. I have three criteria. In rough order of importance:

* Creation burden
* The effort invested in creating the code to begin with. Part of this is the quality of the language and libraries you're working in.
* Maintenance burden
* The effort invested in keeping your code working, whether due to bugfixes, general bitrot, or needing to add new features.
* Performance burden
* The memory, computational power, and bandwidth required to run your code. All else being equal, code that performs better is preferable.

## Therefore...

### *The best code is code that accomplishes your goals, and...*


### *was never written by you or anyone else.*

The gold standard. Code that wasn't written has no creation burden, no maintenace burden, and zero performance burden. If you can avoid writing or using code, you should absolutely do so.

### *was written well by someone else, and is maintainned by someone else, but the source is open so that you can maintain it if you need to.*

A well-written, well-maintained open-source library is a glorious thing. Not only will this spare you the vast majority of creation and maintenance burdens, but it'll allow you to maintain it in the event that it becomes unmaintained, or you need to add some feature. However, all three burdens depend heavily on the quality of the library, so always be wary of that.

### *was written well by someone else, and is unmaintained, but the source is open.*

You've found the perfect library, but someone wrote it and dropped it? Still absolutely worthwhile to use. The maintenance burden is likely to be higher than code you wrote yourself, but this is almost always beaten out by the lack of a creation burden. Again, code quality is a factor in all three burdens.

### *was written by you, but maintained by someone else*

Nice work if you can get it. Finally we arrive at code written by you. We're just going to assume it's well written, because we'd never write poorly written code, right? Notice how low writing the code yourself is on this list.

### *was written by you, and maintained by you*

Ah, finally. This item is well into the middle of the list, but it should form the literal majority of your time. It takes a ton of effort and time to create and maintain code. You should try to do this as little as possible.

### *was written poorly by someone else.*

Oh no. You've included a library, and it gnaws through memory like crazy and throws strange errors that take hours to debug. You've just created a huge maintenance burden for yourself fixing this broken library. Switch libraries if you can. If you can't, it may literally be better to create your own.

### *was written by someone else, but the source is closed*

It doesn't matter how good or bad the implementation is here. Once you you use a closed source library, you're at the whims of someone else. If they discontinue it unexpectedly? Suddenly you've got to scramble to find and implement a replacement. If they were the only library doing the thing you wanted, you may need to create an entire library from scratch during a business-critical timeframe. If there's some bug? Report it to them and HOPE they fix it in a timely manner. If they stop maintaining it? You're just out of luck.

Avoid.

## Conclusions

So should you code everything as bash scripts gluing together pre-existing pieces of software? Well, no. You have other design goals that you need to achieve. For example, you probably need the finished software to run at least X times per second, or work across multiple platforms, or any one of an infinite number of design goals. The best code is code that falls high in this list AND meets your design criteria.

That said, it does mean that you shouldn't over-engineer your solutions.

Now, if I could just learn this lesson myself I'd be so much better off.

Cheers!



Loading…
Cancel
Save