Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As usual with code principles/guidelines, it's about knowing when to apply them, and how much to apply them. In the particular scenario discussed in the article, I think the better option would have been something in between.

I think most devs go through learning phases with code guidelines, code patterns and the like, when they first hear about them, actively trying to crowbar them into every line of code, even if it results in more complex code - because they treat these things as laws, rather than guidelines.

IME, good devs eventually grow out of this, and from experience are much better able to apply guidelines and patterns when it's "suitable" to do so.

This problem is sometimes exacerbated by management, who like to focus on metrics. For example, a project I recently worked on used SAST (SonarCloud), with all sorts of arbitrary restrictions enabled: less than 3% duplicated code, minimum 90% test coverage etc. Predictably, it helped make the code more complex than it needed to be, and led to mock-heavy unit tests that didn't seem to actually test anything - they existed only to satisfy SonarCloud (and ergo, management).



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: