It's clearly secondary to correctness: A program that is well-written but doesn't work right is worthless. Many hairy balls of mud have shipped to great acclaim.
Human readability & comprehension is nice for maintenance, but you don't get to maintain something that never worked right to begin with.
… Of course, Windows is existence proof that you can be successful with neither.
The point the post makes is that one can't write (or ensure that) a piece of code is correct without understanding it in the first place.
It's most important, above these, because you cannot ensure any of these other design goals without understandability. It has to come first
And I agree with that. Correctness is the goal, but making the code readable is the way: it comes first. Cutting corners there is a good way to shoot yourself on the foot.
A program that works right but doesn't solve the problem is also not very useful.
Too often, you won't be given time to make your software understandable. Probably almost never. So you have to incorporate a way of programming that leaves your code more understandable after you fixed your bug or added your feature.
I don't know if understandability is the most important thing. However I certainly agree with the author that it's curcial, if you ever want to do more than merley a script or a proof of concept.
So write it properly from the get-go. You can get 90% of the way by naming things properly and following the Single Responsibility Principle.
The most important part of part of programming is learning to understand software
It's clearly secondary to correctness: A program that is well-written but doesn't work right is worthless. Many hairy balls of mud have shipped to great acclaim.
Human readability & comprehension is nice for maintenance, but you don't get to maintain something that never worked right to begin with.
… Of course, Windows is existence proof that you can be successful with neither.
The point the post makes is that one can't write (or ensure that) a piece of code is correct without understanding it in the first place.
And I agree with that. Correctness is the goal, but making the code readable is the way: it comes first. Cutting corners there is a good way to shoot yourself on the foot.
A program that works right but doesn't solve the problem is also not very useful.
Too often, you won't be given time to make your software understandable. Probably almost never. So you have to incorporate a way of programming that leaves your code more understandable after you fixed your bug or added your feature.
I don't know if understandability is the most important thing. However I certainly agree with the author that it's curcial, if you ever want to do more than merley a script or a proof of concept.
So write it properly from the get-go. You can get 90% of the way by naming things properly and following the Single Responsibility Principle.
The most important part of part of programming is learning to understand software