8 ms·

I strongly disagree on this one. 10+K lines files are absolutely unreadable most of the time. Separating business logic than other parts of the application help

I strongly disagree on this one. 10+K lines files are absolutely unreadable most of the time. Separating business logic than other parts of the application helps maintaining it and making everything evolve in parallel, without mixing things up. It also helps to clearly see where business logic happens.

pshirshov 4y ago
And of course it's lot easier to read 200k+ LoC shattered around twenty repos.
- koliber 4y ago
  The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. I'm a proponent of keeping things in a monolith as long as possible. Break code into files. Organize files into modules. A time may come when you need to separate out services. Often, people break things out too early, and don't spend enough effort on thinking how to break things up or on the interfaces.
  - rightbyte 4y ago
    > The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. You can say the exact same thing about C-headers though.
  - pshirshov 4y ago
    > and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. Don't you want determinism and deterministic simultations? If you do, you'll also need stub implementations (mocks, dummies) for your interfaces. Some notes on that: https://blog.7mind.io/constructive-test-taxonomy.html https://blog.7mind.io/constructive-test-taxonomy.html > A time may come when you need to separate out services. Most likely it won't if you organise properly. For example, if each your component is an OSGi module.
- SomeoneOnTheWeb 4y ago
  No, to me that's equally as bad. But 100k lines split across 500 well-named files is a lot easier to work with than 10+K line files or multi-repo code.
  - naasking 4y ago
    With an IDE you're can just look at the class hierarchy/data types rather than the files. As long as those are well organized, who cares hoe they span files? For instance, in C# a class can span multiple files using "partial" or you can have multiple classes in a single file. It's generally not an issue as long as the code itself is organized. The only downside is the reliance on an IDE, which is pretty standard these days anyway.
karamanolev 4y ago
I'm inbetween. 10K line files are usually extremely messy, but they can be written not to - a large number of well-organized, well-capsulated <100 LOC classes can be very readable if smashed together in one file. It just so happens that people who tend to write readable self-contained classes just don't put them in 10 KLOC files, but rather split them. And vice-versa, creating an association "10 KLOC files are unreadable", where it's not the length of the file, but rather the organization itself. Same for business logic - very clear separation can be cumbersome sometimes, but otherwise it becomes messy if you're not careful. And careful people just tend to separate it.
- sbergot 4y ago
  I disagree with this stance. Creating a file and naming it gives it a purpose. It creates a unit of change that tools like git can report on.
  - beagle3 4y ago
    git diff understands function boundaries, and for many languages will “report” equally well on a single file. It’s a good idea to break things down to files along logical boundaries. But got reporting isn’t a reason. edit: "got diff" -> "git diff". DYAC and responding from mobile!
    - joshuamorton 4y ago
      Git diff absolutely does not understand function boundaries, it's diff algorithms routinely confuse things like adding a single new function, thinking that the diff should begin with a "}", instead of a function definition.
  - nonethewiser 4y ago
    A line is a unit of change that git can report on. If it's a separate file that is scoped to some specific concern, sure. But its tgat grouping by concern that is key. Not separation into another file. Extracting ra dom bits of code into separate files would be _worse_.
surprisetalk 4y ago
Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files? And why do you think the overhead of maintaining the extra code for module boundaries is worth it? EDIT: And what editor do you use? I'm wondering if a lot of these differences come down to IDEs haha
- bombolo 4y ago
  > EDIT: And what editor do you use? I'm wondering if a lot of these differences come down to IDEs haha Yes java developers can't do anything without their IDE. It helps them mask the 30000 nested directories they've created to "organize" the code.
- nonethewiser 4y ago
  > Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files? This is a fair point but assumes 1 particular use case. It is easier if you are just concerned with a bit of it. If you need to deal with all of it, yeah, good fucking luck. 10k LOC file or 1k 100 LOC files.
- SomeoneOnTheWeb 4y ago
  10+K lines spread across 1k file is equally as bad as 10+K line files IMO. I tend to ensure each file serves exactly one purpose (e.g. in C# one file = one class, with a only few exceptions). I use VS Code, but in every IDE with a file opening palette it's actually really fast: you want to look for the code to, let's say, generate an invoice, just search for "invoice" in the list of files and you'll find it immediatly. (Also modules have their own problem, I was mainly talking in a general way since that's what the parent comment was talking about.)
- osigurdson 4y ago
  The right answer is 20 files with 500 lines in each - i.e. few pages of clean/ readable/logical/well-factored code. Obviously it depends on the code itself - it's is fine to have longer files if highly correlated. Stateful classes should be kept short however as the cognitive load is very high. I also find that updating code to take advantage of new/better language features / coding styles, etc. is impossible to do on a large code base at once. However, sprinkling these kind of things randomly leads to too much inconsistency. A reasonable sweet spot is to make each file self-consistent in this regard. My experience stems from larger 500+ person-year projects with millions of lines of code.

pshirshov 4y ago

And of course it's lot easier to read 200k+ LoC shattered around twenty repos.

koliber 4y ago
The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. I'm a proponent of keeping things in a monolith as long as possible. Break code into files. Organize files into modules. A time may come when you need to separate out services. Often, people break things out too early, and don't spend enough effort on thinking how to break things up or on the interfaces.
- rightbyte 4y ago
  > The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. You can say the exact same thing about C-headers though.
- pshirshov 4y ago
  > and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. Don't you want determinism and deterministic simultations? If you do, you'll also need stub implementations (mocks, dummies) for your interfaces. Some notes on that: https://blog.7mind.io/constructive-test-taxonomy.html https://blog.7mind.io/constructive-test-taxonomy.html > A time may come when you need to separate out services. Most likely it won't if you organise properly. For example, if each your component is an OSGi module.
SomeoneOnTheWeb 4y ago
No, to me that's equally as bad. But 100k lines split across 500 well-named files is a lot easier to work with than 10+K line files or multi-repo code.
- naasking 4y ago
  With an IDE you're can just look at the class hierarchy/data types rather than the files. As long as those are well organized, who cares hoe they span files? For instance, in C# a class can span multiple files using "partial" or you can have multiple classes in a single file. It's generally not an issue as long as the code itself is organized. The only downside is the reliance on an IDE, which is pretty standard these days anyway.

karamanolev 4y ago

I'm inbetween. 10K line files are usually extremely messy, but they can be written not to - a large number of well-organized, well-capsulated <100 LOC classes can be very readable if smashed together in one file. It just so happens that people who tend to write readable self-contained classes just don't put them in 10 KLOC files, but rather split them. And vice-versa, creating an association "10 KLOC files are unreadable", where it's not the length of the file, but rather the organization itself. Same for business logic - very clear separation can be cumbersome sometimes, but otherwise it becomes messy if you're not careful. And careful people just tend to separate it.

sbergot 4y ago
I disagree with this stance. Creating a file and naming it gives it a purpose. It creates a unit of change that tools like git can report on.
- beagle3 4y ago
  git diff understands function boundaries, and for many languages will “report” equally well on a single file. It’s a good idea to break things down to files along logical boundaries. But got reporting isn’t a reason. edit: "got diff" -> "git diff". DYAC and responding from mobile!
  - joshuamorton 4y ago
    Git diff absolutely does not understand function boundaries, it's diff algorithms routinely confuse things like adding a single new function, thinking that the diff should begin with a "}", instead of a function definition.
- nonethewiser 4y ago
  A line is a unit of change that git can report on. If it's a separate file that is scoped to some specific concern, sure. But its tgat grouping by concern that is key. Not separation into another file. Extracting ra dom bits of code into separate files would be _worse_.

surprisetalk 4y ago

Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files? And why do you think the overhead of maintaining the extra code for module boundaries is worth it? EDIT: And what editor do you use? I'm wondering if a lot of these differences come down to IDEs haha

bombolo 4y ago
> EDIT: And what editor do you use? I'm wondering if a lot of these differences come down to IDEs haha Yes java developers can't do anything without their IDE. It helps them mask the 30000 nested directories they've created to "organize" the code.
nonethewiser 4y ago
> Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files? This is a fair point but assumes 1 particular use case. It is easier if you are just concerned with a bit of it. If you need to deal with all of it, yeah, good fucking luck. 10k LOC file or 1k 100 LOC files.
SomeoneOnTheWeb 4y ago
10+K lines spread across 1k file is equally as bad as 10+K line files IMO. I tend to ensure each file serves exactly one purpose (e.g. in C# one file = one class, with a only few exceptions). I use VS Code, but in every IDE with a file opening palette it's actually really fast: you want to look for the code to, let's say, generate an invoice, just search for "invoice" in the list of files and you'll find it immediatly. (Also modules have their own problem, I was mainly talking in a general way since that's what the parent comment was talking about.)
osigurdson 4y ago
The right answer is 20 files with 500 lines in each - i.e. few pages of clean/ readable/logical/well-factored code. Obviously it depends on the code itself - it's is fine to have longer files if highly correlated. Stateful classes should be kept short however as the cognitive load is very high. I also find that updating code to take advantage of new/better language features / coding styles, etc. is impossible to do on a large code base at once. However, sprinkling these kind of things randomly leads to too much inconsistency. A reasonable sweet spot is to make each file self-consistent in this regard. My experience stems from larger 500+ person-year projects with millions of lines of code.