3 ms·

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 ass

by 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.

by jzoch 7y ago

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.