4 ms·

That coincides with the following: > Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often

That coincides with the following: > Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1] This is also noted in PEP8: > One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".[2] [1]: https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-code https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-cod... [2]: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds https://www.python.org/dev/peps/pep-0008/#a-foolish-consiste...

RaiseProfits 7y ago
Who would have thought the best argument against an 80 character cap in pep8 would come from guido himself?
- icebraining 7y ago
  Anyone who charitably reads what he writes.
hinkley 7y ago
I’m finding that one of the biggest time sinks is code that looks like it’s doing something other than what it’s actually doing. Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature. One of the wisdoms of XP, I think. The code you touch the most should be the sanest.
jodrellblank 7y ago
> Code is read many more times than it is written I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable". And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on. I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard. But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?

RaiseProfits 7y ago

Who would have thought the best argument against an 80 character cap in pep8 would come from guido himself?

icebraining 7y ago
Anyone who charitably reads what he writes.

hinkley 7y ago

I’m finding that one of the biggest time sinks is code that looks like it’s doing something other than what it’s actually doing. Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature. One of the wisdoms of XP, I think. The code you touch the most should be the sanest.

jodrellblank 7y ago

> Code is read many more times than it is written I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable". And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on. I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard. But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?