4 ms·

People don't voluntarily read code because most code isn't readable.

jzoch 7y ago
That is a reason people do not read code, but imo not the primary one. I don't read code because, unless I am forced, it is a waste of time. I used to grade assignments for an intro CS class @ Stanford, and if I had to read your helper functions it was because your code didn't work. Not because I wanted to. Not to start wars, but imperative code especially is a waste of time to read unless forced, as I need to understand your desired goal AND how you chose to get there. See for + if vs filter, for example. I would rather just read a function comment or class comment or some doc instead (assuming its up to date...)
- ahartmetz 7y ago
  Sounds like you haven't read much good code. I have worked on a lot of "reasonably good" code I didn't mind reading. Reasons for code to be good or bad vary. The Linux memory management code (linux/mm), for example, is rather hard to read, but also a big technical accomplishment. So it's still interesting (and I read it just out of interest). Code that pushes around data is nice if it's well organized and named. Etc.
  - jzoch 7y ago
    No I've read good code. At work you don't have the liberty to sit and understand every line of a library you're using does or some other teams work. I did not say code should not be read, just that it shouldn't be expected to be read. Make it clear before you ever get to the code what's going on
- derefr 7y ago
  What's your opinion on the Lisp paradigm of creating a DSL that reflects the problem domain, and then encoding the solution to the problem—in a readable way—directly in this problem-domain embedding? Sort of like the more generalized form of what BDD is supposed to allow non-developers to do, where there's no requirement that anyone be able to change the code quickly, just a requirement that they be able to easily audit and understand the code from the code itself.
Nasrudith 7y ago
Really code is meant to be read like a map or diagram and not a poem.
derefr 7y ago
And there is no concerted effort to make code readable, because most code will exist for its entire lifetime without anyone attempting to read it. People who need to get up to speed to become new maintainers for such codebases will sit down and grok the codebase, by poking it with tooling, exploring APIs, etc. until they get a sense of it—sort of like getting a sense of a city. But even they won't ever just sit down and read through the code, because they know it wasn't written for that. It's a bit of a vicious cycle. The question is: which part of the cycle is easiest to break?

That is a reason people do not read code, but imo not the primary one. I don't read code because, unless I am forced, it is a waste of time. I used to grade assignments for an intro CS class @ Stanford, and if I had to read your helper functions it was because your code didn't work. Not because I wanted to. Not to start wars, but imperative code especially is a waste of time to read unless forced, as I need to understand your desired goal AND how you chose to get there. See for + if vs filter, for example. I would rather just read a function comment or class comment or some doc instead (assuming its up to date...)

ahartmetz 7y ago
Sounds like you haven't read much good code. I have worked on a lot of "reasonably good" code I didn't mind reading. Reasons for code to be good or bad vary. The Linux memory management code (linux/mm), for example, is rather hard to read, but also a big technical accomplishment. So it's still interesting (and I read it just out of interest). Code that pushes around data is nice if it's well organized and named. Etc.
- jzoch 7y ago
  No I've read good code. At work you don't have the liberty to sit and understand every line of a library you're using does or some other teams work. I did not say code should not be read, just that it shouldn't be expected to be read. Make it clear before you ever get to the code what's going on
derefr 7y ago
What's your opinion on the Lisp paradigm of creating a DSL that reflects the problem domain, and then encoding the solution to the problem—in a readable way—directly in this problem-domain embedding? Sort of like the more generalized form of what BDD is supposed to allow non-developers to do, where there's no requirement that anyone be able to change the code quickly, just a requirement that they be able to easily audit and understand the code from the code itself.

Nasrudith 7y ago

Really code is meant to be read like a map or diagram and not a poem.

derefr 7y ago

And there is no concerted effort to make code readable, because most code will exist for its entire lifetime without anyone attempting to read it. People who need to get up to speed to become new maintainers for such codebases will sit down and grok the codebase, by poking it with tooling, exploring APIs, etc. until they get a sense of it—sort of like getting a sense of a city. But even they won't ever just sit down and read through the code, because they know it wasn't written for that. It's a bit of a vicious cycle. The question is: which part of the cycle is easiest to break?