4 ms·
My opinion is that maintainable code is written first for reading by humans and second for executing by computers. Unless I'm writing throwaway prototype code
by aaronbrethorst 4y ago
My opinion is that maintainable code is written first for reading by humans and second for executing by computers.
Unless I'm writing throwaway prototype code (famous last words, lol), I try to write code such that I will be able to figure out what my intention was 6-18 months from now when I'm staring at a piece of code in a panic trying to debug a production issue.
That doesn't mean I'm going to get it right when I write this code. Instead, I'll be able to better ascertain what my assumptions were, how they fell apart in practice, and what a minimal, correct fix that doesn't make things worse might be.
Edit: Incidentally, this also applies to my commit messages. I’m writing them primarily for my future self so that I can figure out WHY I made a change, not WHAT the change was.
- deleted 4y ago[deleted]
- Karellen 4y ago> My opinion is that... You make it sound like you came up with that all by yourself
- aaronbrethorst 4y agoNah, I stand on the shoulders of generations of developers, just like everyone else here. I didn’t claim my opinion was novel, just that it’s mine. I hope others share my opinion, because I’d find codebases that fit my criteria easier to maintain than many other types. Also, do you agree or disagree with any of the ideas I put forth?
- Karellen 4y agoI don't disagree, I just think it's only right to credit the original authors when you use their exact phrasing.
- Rexxar 4y agoI think we have a problem if we need now to credit the original "author" of every opinion we have.
- aaronbrethorst 4y agoWhich original authors am I unintentionally plagiarizing? I’m not usually that adept at quoting verbatim, especially when I’ve completely forgotten who I’m quoting.
- Karellen 4y ago> programs must be written for people to read and only incidentally for machines to execute. -- Abelson & Sussman, The Structure and Interpretation of Computer Programs, 1984 FWIW, I already provided the quote, with the source, in these comments, 3 hours before you wrote yours. (ok, it's not exactly verbatim. But I think it would get counted as plagarism in almost any context reasonably imaginable.)
- aaronbrethorst 4y agoAhh, I apologize for not thoroughly reading the entire comment thread before posting mine. Otherwise I would've upvoted you and said "+1" or something to that effect. I certainly didn't mean to hurt your feelings. And also thanks for jogging my memory on the source. SICP remains one of my favorite textbooks from college, although it's been about 20 years and so everything's fuzzier than it used to be. Have a great weekend.
- Shorel 4y agoMy opinion is that you can write code that's easy to understand, and it is also good for the computer to run. One thing is not in contradiction with the other. It could lower the reusability of the code, by not having many abstractions, but it will be easy to understand, concise, and it will do what it was written for very well.
- moffkalast 4y agoIt should be written so it's easy for humans to understand first. If that's too slow, then it can be optimized so it's fast, if a bit less readable. 9 times out of 10 it won't be too slow in the first place these days, unless you know beforehand that you need maximum speed for valid reasons.
- aaronbrethorst 4y agoYep exactly
- Shorel 4y agoYour opinion sounds too one-sided to me. That complete disregard for performance is what gave us the endless Electron clients eating CPU/RAM just to do basic chat and music playing stuff. If the code is written with care for both things, readability and speed, the actual state of things would not be so wasteful. You don't need to make it difficult to understand. Just don't disregard performance as an afterthought.