Encapsulation and modularization is necessary, nothing more.
If you get this right, you can get away with a bunch of crappy thing, because you can easily throw them out in the future and reimplement them better.
If you get this right, you can get away with a bunch of crappy thing, because you can easily throw them out in the future and reimplement them better.
- each single line uses a different formatting style
- variable names are hard to read abbreviations
- variable/class names don't make sense
- 5 is a level of indentation easily reached
- there's almost as much dead code as live code
- comments are grammatical nonsense and don't explain why the code is written the way it is
But yes, I prefer those things too, haha
> When you’re working with high leverage, you don’t have to put as much investment in to get the same functionality or value out. Because your code is simpler and easier to create, it can be considered disposable. And with disposable code, you don’t feel the compulsion to keep it, like you would with the old paradigm boat anchor projects. It all adds up to this: data orientation drives antifragility, enabling you to change individual vectors, and your entire organization more swiftly.
http://blog.cognitect.com/blog/2016/6/28/the-new-normal-data...
The implication is that when your code becomes less important the data model becomes more important in response.
But I think my statement is idependent from project size. I've seen it in big and small projects alike. As long as you get this fundamental thing right, you can get away with more than you think.
Did you know that "decomification" [1] is considered by the Mozilla project to be a "good thing"? And it doesn't mean fighting communism.
But like anything (just like COM), decomification can also be taken too far, and can lead to decomificationphobia [2]:
"Also in this way every class could be deComed leaving no risk of overdeComification. But since I don’t quite know the justification or use case for xpcom in mozilla, I find this decomification quite scary."
This fashionable de-over-modularization technique is also fondly known as "deCOMtamination" [2]:
"In Gecko, XPCOM or a primordial form of it was overused inside Gecko, where there are (or should be) no DLL boundaries, for private APIs that are not usable by other, independently evolving code. The overhead here in code space and runtime is significant (we will quantify it as we go), and deCOMtamination consists of getting rid of this bogus COM-like glue."
Mozilla has even developed automated deCOMtamination tools [3]:
"This is an update on the ongoing deCOMtamination work from the automated rewriting perspective. I think it’s pretty exciting that Mozilla is the first large-scale C++ project to attempt automated large scale source code cleanups and optimizations. I think the tools are finally getting mature enough for the job."
"The downside is that there isn’t a published roadmap of what we are planning to achieve with deCOMtamination as we are still in the planning stages. The upside is that there is still time for any interested parties to think up the next great improvement on how things are done, checkout the refactoring toolchain and either extend an existing tool or implement a new one."
[1] https://www.google.com/search?q=decomification&oq=decomifica...
[2] https://blog.mozilla.org/tglek/2007/01/03/squashed-and-compi...
[3] https://blog.mozilla.org/tglek/category/decomtamination/