Lines can be a noisy way to look at the complexity of a module or component. I'd look at the complexity first in terms of:
Dependencies: How many other modules does this module import. How many components does this component utilize?
Then Branches and Blocks and Statements: How much of the logical weight does this component lift?
What you'll find is that the two work inversely to each other, and that by breaking up a component into smaller functions (hooks, components, utils, ect.) you increase the dependencies that code needs to work.
There is a way to handle both of these concerns simultaneously, and that is to write more generalized code. This allows you to break things up without introducing as many explicit dependencies between things. This introduces another measure of complexity though:
Abstraction: I'll just put this as "Patterns which aren't explicitly in the code".
The way to handle this axis of complexity is to put more into the code, like using TypeScript over JavaScript, or writing unit tests. You can also document abstractions, but this can get out of date, and so being careful about introducing abstract ideas into the code is usually helpful.
That's just my thinking, and I'd have to look at an example to have a solid opinion whether 1000 lines of code is the right balance of all these ideas. Share a link and I'll skim it!
I didn't see the links in your post! So here's what I would say briefly. If you look at react select for example:
Dependencies: This component has very few dependencies
Logical Weight: This single component lifts a lot of logical weight, and I see methods and things that could be standalone functions or components.
Abstraction: This is heavy on abstraction (it defines a component class, which is a huge abstraction), but the use of TypeScript puts more of that machinery in code.
Would I break this up into more modules? I think that would depend on the time available, but ideally I think it could have more dependencies at the benefit of being less individually complex in my opinion. Hope that helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lines can be a noisy way to look at the complexity of a module or component. I'd look at the complexity first in terms of:
What you'll find is that the two work inversely to each other, and that by breaking up a component into smaller functions (hooks, components, utils, ect.) you increase the dependencies that code needs to work.
There is a way to handle both of these concerns simultaneously, and that is to write more generalized code. This allows you to break things up without introducing as many explicit dependencies between things. This introduces another measure of complexity though:
The way to handle this axis of complexity is to put more into the code, like using TypeScript over JavaScript, or writing unit tests. You can also document abstractions, but this can get out of date, and so being careful about introducing abstract ideas into the code is usually helpful.
That's just my thinking, and I'd have to look at an example to have a solid opinion whether 1000 lines of code is the right balance of all these ideas. Share a link and I'll skim it!
I didn't see the links in your post! So here's what I would say briefly. If you look at react select for example:
Would I break this up into more modules? I think that would depend on the time available, but ideally I think it could have more dependencies at the benefit of being less individually complex in my opinion. Hope that helps!