A lot of debate around the book seems to be in its context
Many modules and small files : Works for OO languages. There are many C projects which are just a single header file due to ease of integration into other projects and being easy to inspect/modify
Making incremental changes is often a better choice than rebuilding from scratch - Again, works for OO languages. Array oriented languages like APL/J/K turn this advice on its head due their terseness and expressivity
First make it work, then make it right - This is not valid for projects which deal with security and formal verification e.g cryptographic libraries, theorem provers, mathematical libraries
A good test suite eliminates your fear of breaking the app during refactoring - Valid for dynamically typed languages. Strongly typed functional languages (e.g Haskell, Idris) have a type system expressive enough for fearless refactoring as long as it compiles
Using many small classes instead of a few large classes in your app reduces the amount of information a developer needs to understand while working on any given task - i have seen this taken to an extreme where there are dozens of classes for doing simple stuff. I have also seen the other extreme "Helper" classes which have >100k LOC
Use dependency injection to give developers the flexibility to pass any object with a matching interface to another class - This is more due to the clumsiness of early Java and C++. Most modern languages have remedied this since
Formatting - Use an agreed upon linter or better still, the language default e.g gofmt and save a lot of time and energy on pointless debates related to this!
Third-party libraries help you ship your product faster by allowing you to outsource various concerns. - In recent times, we are seeing the cost of this in terms of security issues in dependencies. Javascript ecosystem has seen multiple issues of either malicious codeshipping or build breakages due to package issues
In short, the book is written as advice for OO Web applications where it makes many good points. Taking the advice out of its context results in cargo cults and code which is not fit for its domain
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.
A lot of debate around the book seems to be in its context
gofmtand save a lot of time and energy on pointless debates related to this!In short, the book is written as advice for OO Web applications where it makes many good points. Taking the advice out of its context results in cargo cults and code which is not fit for its domain