It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
The idea of "files" is, for the most part, an abstraction developed to help people make sense of the contents of a disk. It's a lot easier to envision chunks of storage as documents with names and extensions and so forth than it is to try to work with byte offsets and lengths. Think of trying to find your way: street signs and buildings and landmarks help you orient yourself by dividing and delimiting space, but if you're lost in the desert, one sand dune looks much like the next.
It is perfectly possible to write programs in a single file in many languages, but tools that allow multiple source files to be "linked" into the finished product date back half a century for a reason: it makes an enormous difference to our ability to comprehend how individual parts of the system work and interact with each other. The ways in which programs may be divided into source files vary wildly depending on language, purpose, convention, and taste. But those are all essentially human factors. It doesn't matter to the computer.
Extending on this, I'd say that my reasoning is that you should split files by logical group, and ensure that they stay on topic. It's quite easy when you look at the difference between a CSS or JS file. However, each of those can be split by topic / purpose. You'll then find that there's opportunity for reuse rather than duplication :-)
I do like that you mention that the notion of "many files" is mostly a human construct, and I agree fully :-D
AgentDenton is right in the sense that files in a program should be logically grouped.
To extend on Dian's awesome answer, the amount of files (or the splitting of files in a program) depends on what programming language you use and what the purpose of your program is. Generally speaking, in a production-ready application (or a service, etc), the program should be split into multiple files that are grouped together based on the behaviour they provide.
For example, if you are building an application that reads files into memory and then puts them in a database, it makes sense to split the multiple steps into files that are grouped accordingly (e.g you can have the file load step, the decoding step and the persistence step).
It is quite important to get a feel for splitting up your program into multiple files so that (and quoting Dian here) it can "help you orient by dividing and delimiting". This also applies to functions, packages (or modules) etc. In object-oriented programming (think Java, C++) one good rule is the "single responsibility principle" which states that "every function, class (in our case file) or module should have responsibility over a single part of the functionality provided by the software". This is basically saying that in most cases (certainly not all or not in all programming languages) your files should do one thing only and do it well. Try using this rule the next time you code a small application and see if it helps your code become more readable and clean.
The idea of "files" is, for the most part, an abstraction developed to help people make sense of the contents of a disk. It's a lot easier to envision chunks of storage as documents with names and extensions and so forth than it is to try to work with byte offsets and lengths. Think of trying to find your way: street signs and buildings and landmarks help you orient yourself by dividing and delimiting space, but if you're lost in the desert, one sand dune looks much like the next.
It is perfectly possible to write programs in a single file in many languages, but tools that allow multiple source files to be "linked" into the finished product date back half a century for a reason: it makes an enormous difference to our ability to comprehend how individual parts of the system work and interact with each other. The ways in which programs may be divided into source files vary wildly depending on language, purpose, convention, and taste. But those are all essentially human factors. It doesn't matter to the computer.
Enlightening! I guess it does depend greatly on the people writing, using, and maintaining the code.
Thank you for your answer!
Extending on this, I'd say that my reasoning is that you should split files by logical group, and ensure that they stay on topic. It's quite easy when you look at the difference between a CSS or JS file. However, each of those can be split by topic / purpose. You'll then find that there's opportunity for reuse rather than duplication :-)
I do like that you mention that the notion of "many files" is mostly a human construct, and I agree fully :-D
AgentDenton is right in the sense that files in a program should be logically grouped.
To extend on Dian's awesome answer, the amount of files (or the splitting of files in a program) depends on what programming language you use and what the purpose of your program is. Generally speaking, in a production-ready application (or a service, etc), the program should be split into multiple files that are grouped together based on the behaviour they provide.
For example, if you are building an application that reads files into memory and then puts them in a database, it makes sense to split the multiple steps into files that are grouped accordingly (e.g you can have the file load step, the decoding step and the persistence step).
It is quite important to get a feel for splitting up your program into multiple files so that (and quoting Dian here) it can "help you orient by dividing and delimiting". This also applies to functions, packages (or modules) etc. In object-oriented programming (think Java, C++) one good rule is the "single responsibility principle" which states that "every function, class (in our case file) or module should have responsibility over a single part of the functionality provided by the software". This is basically saying that in most cases (certainly not all or not in all programming languages) your files should do one thing only and do it well. Try using this rule the next time you code a small application and see if it helps your code become more readable and clean.
(ref: en.wikipedia.org/wiki/Single_respo...)