I've selected MarkdownProvider.ts for refactoring, which is a module of 92 lines of code and 22 incoming calls. Addressing this will make our codebase more maintainable and improve Better Code Hub's Separate Concerns in Modules guideline rating! 👍
Here's the gist of this guideline:
- Definition 📖
Avoid large modules with high fan-in (nr. of incoming calls).
- Why❓
This keeps the codebase loosely coupled which makes it easier to minimize the consequences of changes.
- How 🔧
Identify and extract responsibilities of large modules into smaller ones and hide implementation details behind interfaces. Target having modules that have no more than 10 incoming calls.
You can find more info about this guideline in Building Maintainable Software. 📖
ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁
Good luck and happy coding! 
✨ 💯
I've selected MarkdownProvider.ts for refactoring, which is a module of 92 lines of code and 22 incoming calls. Addressing this will make our codebase more maintainable and improve Better Code Hub's Separate Concerns in Modules guideline rating! 👍
Here's the gist of this guideline:
Avoid large modules with high fan-in (nr. of incoming calls).
This keeps the codebase loosely coupled which makes it easier to minimize the consequences of changes.
Identify and extract responsibilities of large modules into smaller ones and hide implementation details behind interfaces. Target having modules that have no more than 10 incoming calls.
You can find more info about this guideline in Building Maintainable Software. 📖
ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁
Good luck and happy coding!
✨ 💯