5 ms·

"Programs must be written for people to read, and only incidentally for machines to execute." This. x1000. I've found that a lot of disagreement about ways to

"Programs must be written for people to read, and only incidentally for machines to execute." This. x1000. I've found that a lot of disagreement about ways to implement a feature can be solved by keeping this in mind.

Alex3917 9y ago
> I've found that a lot of disagreement about ways to implement a feature can be solved by keeping this in mind. I dunno, the usual reactions I get are more in line with the comments on this Stack Overflow post: http://stackoverflow.com/questions/43377533/should-python-errors-be-documented-in-code-or-comments http://stackoverflow.com/questions/43377533/should-python-er... For whatever reason, making the case that code that actually performs some useful computation should be closer to the exception rather than the rule tends to result in people completely losing their shit.
- deleted 9y ago
  [deleted]
- 3pt14159 9y ago
  I think the issue is that people don't want overhead. I don't want to wade through 12 lines of useless try raises to get my work done. I want to be able to enumerate the exceptions when I need them. For example, I may want to call my_function.possible_exceptions, but there is an issue here as well, two exceptions may be raised with different messages, so the class of the exception alone is not an acceptable identifier of what the exception is. Even attempts to create, say, a global register of unique exceptions would fail because of how dynamic a language like Python is. In general readability of code has more to do with something like this: valid_filename = filename.ends_with? ".txt" return File.open(filename) if valid_filename Versus something like this: return File.open(fn) if fn.ends_with? ".txt" The former uses a longer variable that clearly shows what it is and reduces the mental overhead of having to figure out why we're returning (because the file is valid, we're finished with this function as intended).
CalChris 9y ago
"Programs must be written for people to read, and only incidentally for machines to execute." Not this. x1. Now if this were true, you would read these programs as you would literature. But you don't. Instead, you only use these programs as you would a tool and then complain when they don't do what you want them to do fast enough or reliably enough. In literature, you have expectations but not certainty about the ending. Only with a bad tool do you expect anything but certainty about the ending. Indeed the hallmark of a good program is that you don't have to read it to know how it ends. Another anti-parallel is that literature (literate programming) admires originality whereas good engineering admires plagiarism.
- newsat13 9y ago
  I am possibly not the only one who prints out code and reads them?
  - protomyth 9y ago
    Did it for code reviews when I was code reviewing C[1]. It really does help. Paper still has a place. Its amazing what you see on a page of paper that doesn't get seen on the screen. 1) which, since I was doing the code reviews, I wasn't allowed to write any production code, because who would review my code? :(
  - mannykannot 9y ago
    And annotate them. A pencil is still the most flexible tool for that.
- deleted 9y ago
  [deleted]
- tveita 9y ago
  There is such a thing as technical writing, I don't think anyone is saying code should be fiction.
- clairity 9y ago
  do you really disagree with the idea that writing code, like writing prose, should strive for human clarity? that you should be able to easily understand it without mental gymnastics? that the writer should revise, rewrite and edit the code, and take pride in succinct clarity? because the computer doesn't give a poop, but people do (including your future self)? you seem to be making ancillary points while being deliberately obtuse about the central one.
piinbinary 9y ago
That really sunk in for me when I realized that the entire point of OO classes (and even functions) is just to arrange the code in a way that makes sense to humans.

Alex3917 9y ago

> I've found that a lot of disagreement about ways to implement a feature can be solved by keeping this in mind. I dunno, the usual reactions I get are more in line with the comments on this Stack Overflow post: http://stackoverflow.com/questions/43377533/should-python-errors-be-documented-in-code-or-comments http://stackoverflow.com/questions/43377533/should-python-er... For whatever reason, making the case that code that actually performs some useful computation should be closer to the exception rather than the rule tends to result in people completely losing their shit.

deleted 9y ago
[deleted]
3pt14159 9y ago
I think the issue is that people don't want overhead. I don't want to wade through 12 lines of useless try raises to get my work done. I want to be able to enumerate the exceptions when I need them. For example, I may want to call my_function.possible_exceptions, but there is an issue here as well, two exceptions may be raised with different messages, so the class of the exception alone is not an acceptable identifier of what the exception is. Even attempts to create, say, a global register of unique exceptions would fail because of how dynamic a language like Python is. In general readability of code has more to do with something like this: valid_filename = filename.ends_with? ".txt" return File.open(filename) if valid_filename Versus something like this: return File.open(fn) if fn.ends_with? ".txt" The former uses a longer variable that clearly shows what it is and reduces the mental overhead of having to figure out why we're returning (because the file is valid, we're finished with this function as intended).

CalChris 9y ago

"Programs must be written for people to read, and only incidentally for machines to execute." Not this. x1. Now if this were true, you would read these programs as you would literature. But you don't. Instead, you only use these programs as you would a tool and then complain when they don't do what you want them to do fast enough or reliably enough. In literature, you have expectations but not certainty about the ending. Only with a bad tool do you expect anything but certainty about the ending. Indeed the hallmark of a good program is that you don't have to read it to know how it ends. Another anti-parallel is that literature (literate programming) admires originality whereas good engineering admires plagiarism.

newsat13 9y ago
I am possibly not the only one who prints out code and reads them?
- protomyth 9y ago
  Did it for code reviews when I was code reviewing C[1]. It really does help. Paper still has a place. Its amazing what you see on a page of paper that doesn't get seen on the screen. 1) which, since I was doing the code reviews, I wasn't allowed to write any production code, because who would review my code? :(
- mannykannot 9y ago
  And annotate them. A pencil is still the most flexible tool for that.
deleted 9y ago
[deleted]
tveita 9y ago
There is such a thing as technical writing, I don't think anyone is saying code should be fiction.
clairity 9y ago
do you really disagree with the idea that writing code, like writing prose, should strive for human clarity? that you should be able to easily understand it without mental gymnastics? that the writer should revise, rewrite and edit the code, and take pride in succinct clarity? because the computer doesn't give a poop, but people do (including your future self)? you seem to be making ancillary points while being deliberately obtuse about the central one.

piinbinary 9y ago

That really sunk in for me when I realized that the entire point of OO classes (and even functions) is just to arrange the code in a way that makes sense to humans.