> Try unravelling that tangled, buggy mess, which looks more like a bowl of angel hair pasta than a finely tuned piece of programming. Industry best practice wo

> Try unravelling that tangled, buggy mess, which looks more like a bowl of angel hair pasta than a finely tuned piece of programming. Industry best practice would have 500 separate files instead. In our commercial reality, we would fire anyone for developing code like this and any business that relied on it to produce software for sale would likely go bust. Having the code in more or fewer files is orthogonal to how tangled the code is. Files are just containers for classes/functions. In most cases it makes no difference to the architecture of a system over how many files the code is split. > The approach ignores widely accepted computer science principles known as "separation of concerns", which date back to the early 70s and are essential to the design and architecture of successful software systems. The principles guard against what developers call CACE: Changing Anything Changes Everything. Again, one doesn't separate concerns over files. You can have code split over 500 files and still have a very nasty case of CACE. > Without this separation, it is impossible to carry out rigorous testing of individual parts to ensure full working order of the whole. Testing allows for guarantees. It is what you do on a conveyer belt in a car factory. Each and every component is tested for integrity in order to pass strict quality controls. At the lower levels, one tests functions or classes, not files, so I don't get the argument he is trying to make that the code is not split in enough files.