3 ms·
I used to stick religiously to <=15, in C#. This was detrimental to understanding only twice, and a fairly small issue even then. Not a ridiculous standard for
by hawkice 11y ago
I used to stick religiously to <=15, in C#. This was detrimental to understanding only twice, and a fairly small issue even then. Not a ridiculous standard for interns who don't have an excellent refactor-sense yet, so I didn't begrudge it back then.
- Dylan16807 11y agoBut in sticking to that standard, what was the effort balance between improving understanding vs. busywork to meet the guideline? Edit: Huh? Why a downvote? For a rule made with the goal of improving understanding, it's great that the rule is not actively detrimental to understanding. But we still need to know how often it actually succeeds vs. having marginal effect. We also need to know what it costs in terms of labor. Without those two bits of info we have absolutely no idea if it was a good rule.
- hawkice 11y agoExtremely low cost -- considering how easy it is to pop in a new private method, no big deal. Seconds, and not that frequently needed. Extremely low benefit -- I wouldn't even notice, and most actually confusing things are bigger scale, like the confusing DAL "abstraction" that I was dragooned into copying from the wider C# community.