And both styles lead to equally unreadable code. If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good.
An average new graduate wouldn't be productive in any codebase in a few days. And even if they were, that's a terribly low bar to set. Software development education sucks and most people have to learn on the job. So why not teach them ways to write more reliable and maintainable code.
That is probably good advice but this style of coding
(which comes down to lawless type classes without inherent utility) does make it much more difficult to read unknown code.
Usually documentation isn't fleshed out in internal modules so I end up flipping between various instances and call sides just to figure out what the type class is supposed to do. This doesn't mean that there aren't valid use cases for this but please don't use it as default.
> If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good.
So if a piece of code for securely transferring funds from one back account to another is not readable by a new graduate in a few days, it's no good?
Should we remove safety abstractions from this code safe in order for the new graduate to be able to understand it in a week?
A large part of software is safety-critical. How can you argue that safe abstractions, which reduce or eliminate faults, are not worth it if they can't be learned in a week or so?
You wouldn't happen to work as an Equifax code-reviewer, would you?
