Splitting up Components best practice
Original message was deleted
Solution
200 lines might be based on how much most people feel comfortable reading 1 file and still believe they can understand that 1 file
500 lines might feel more confusing initially, but IMHO we should aim towards understanding whole features, not just 1 single file at a time,, and that will always feel uncomfortable in new code base, so some people might decide to optimize file structure since that is easier to measure, "features" are vague and arbitrary units, "files" are hard and objective
at around 1000 lines, almost all people start to feel it's "too much" no matter how you explain the benefits of colocation, so the team might start having difficulty attracting new developers to make the project sustainable even if there were good reasons for bigger files,,, so most teams decide to draw the line before 1000 lines (even if larger files might exist "temporarily", everyone on team will probably agree it's not ideal situation, that it can only happen due to "technical debt")
500 lines might feel more confusing initially, but IMHO we should aim towards understanding whole features, not just 1 single file at a time,, and that will always feel uncomfortable in new code base, so some people might decide to optimize file structure since that is easier to measure, "features" are vague and arbitrary units, "files" are hard and objective
at around 1000 lines, almost all people start to feel it's "too much" no matter how you explain the benefits of colocation, so the team might start having difficulty attracting new developers to make the project sustainable even if there were good reasons for bigger files,,, so most teams decide to draw the line before 1000 lines (even if larger files might exist "temporarily", everyone on team will probably agree it's not ideal situation, that it can only happen due to "technical debt")
