I’m afraid I’ve come up with a new cutting remark in relation to a code review:
You must really like typing
It applies to both coding and the use of tooling. In the case of tooling, if you constantly type things out the long way, rather than using command short-cuts or the helpers within your IDE that can do things for you, then you deserve all the RSI that you get.
As far as code is concerned, while nobody thinks that code should be that weird cryptic character soup that some languages, like Perl, might seem to encourage, it’s fair to say that there are short ways and long ways of expressing the same code clearly.
For me, it comes down to three issues:
- Terse crisp naming
- Articulate expression of method
- DRY – don’t repeat yourself – or SPYCM – Stop Pasting You Code Monkey
Of these, the last is the greatest sin against maintainable code. Bizarrely, though, duplication of some lines of test code can make tests more readable, but that’s the subject of another discussion.
So Why Does This Even Matter If The Code Works?
Define the code works. If it seems to work when you use it, and there are no unit tests, then you’ve got more work to do to build those unit tests. If there are unit tests based on its behaviour, then you can easily and safely refactor it and why would you not refactor code if there was some benefit to be gained?
That didn’t answer the question… did it?
No. That was the opening premise to demonstrate that this stuff should be easy to do, increasing its value density. It also is essential to point out that poorly tested code is almost as bad as code that doesn’t work.
So why does it even matter… etc…
The ratio of time spend creating code to time spend reading and maintaining that code is surprising. You might spend 10 times more time working on code after the fact than you spent making it in the first place. During the process of creating code, you have a lot more context in your short term memory, which expires for the original developer and takes time to establish in developers new to the code.
For busy areas of the code, the ratio of effort creating to effort reading/maintaining could be closer to 1:100. For libraries, especially the APIs of widely shared libraries, think 1:1,000,000.
Ironically, this is getting long winded
Yeah, I must really like typing, eh?
I hope this reads easily and builds a sense of understanding of the intent behind my words.
If not, please provide feedback during the critical peer-review process and I’ll clear it up.