User:Average/SeparabilityOfDomains

In an earlier era, this was called "structured programming". Then, after that "modular programming". The idea is that you want your logic to be well-defined in separate functional domains rather than all blended into one big block of machine code, or one big function/procedure. Related, don't spread the same conceptual logic across several functions, put them in one and call it from the others. To understand how to do this well, you have to know your data architecture and it`s future. When you take this into account and have refactored enough times, your code is the work of the master.

But the real purpose of "modular" programming isn't to create modules, it is to create more sophisticated conceptual structures -- allowing better logic. This is the lesson learned after painful trials of enterprise coding, for only when you have mastered the problem domain do you really understand how to code it.

Line breaks and block structure - how well can you keep concepts separate without adding clutter are part of the syntactical solutions to separating logic structure.

So programming languages have keywords, AND they have mathematical operators which are kept in their own category separate from keywords, because math is conceptually separate (i.e. a separate domain) from logic flow. The pointer symbol (*) in C should be connected to the type, not the variable name (this is where C programmers are totally wrong and students get confused). The domains you're separating are hardware<->software and a variable name gets you right down to the bits. You get the picture?

Exercise: Imagine keywords being used for all math operations in your code rather than +/- symbols, you'd see that you can't tell what your code is doing at a glance anymore. The best you could hope for is to make them upper-case, so as to be distinct from your flow-logic keywords.

If you're using a lot of local variables, you might be failing this crucible and divided the problem along the wrong lines. Temporary variables and indexes, of course, are accepted. But perhaps you are merely ClothingYourData and forming little micro-domains to make the logic clear. Here you sacrificing a different rule: MinimizeWork and, unless your program is a teaching tool for the concept you're implementing, best not to do it.

Another example, is object mix-ins. Mix-ins should never have data tagging along, otherwise you should just make another object name. Mix-ins should be for adding methods or method-aliases. If you're keeping data, you've probably broken and co-opted the original object's domain.

In C/C++, a function definition allows the specification of variable names with the expected type inside a parameter list. This demonstrates separability of domains by specifying the list of values/variables to be expected (rather than an ambiguous stack say), while also giving an example of ClotheYourData, as your variables are not arbitrary things anymore, but clothed with a pre-specified type. Why does Python drop this? to create a greater domain. By not having pre-specified types, you gain the ability to make collections easily. So they've dropped ClotheYourData by not having hard typing, but gained a new, separate domain that opens up new possibilities of programming.

Object-Orientation provides the way to maximize the value of your processor by optimizing the relationship to data. As data gets more complex, the more you need it. Stroustrup lists three primary components: Encapsulation, Polymorphism, and Inheritance. The most valuable idea is encapsulation -- making all strongly-coupled components travel around with each other, so that the only thing left is the more clumpier, loosely-coupled ones: interfaced through your APIs. Previously, before OOP, it was your file set: filenames, fileset structure, and dependencies. Encapsulation is gold. Polymorphism (the ability for objects to act differently, depending on the types passed to them) is not necessary and may even be a harmful to our goals. Inheritance is a double-edged sword, so in order to cut your own head off with that aspect, you have this document. We're going to improve that list by adding Uniformity. Rather than having hundreds of APIs essentially creating many domain-specific languages, we'll have one universal one, much like all your household appliances have one interface to connect to the power grid. The gOOP separates the domains of passing data and processing it. Are we awesome or what?

Another thought: the reason C++ can't replace C nor become the OOP language of choice, is because it breaks the separation of domains. The domain of C was super efficient code that matched the machine, OOP`s purpose is different and you need a level of indirection to make it work in C. C++ remains a good exploration, like Python did with Object unification, but ultimately failing to reach the goal.

In any event, this one is one of the most powerful ideas and also one of the toughest to master. The idea is that you want non-overlapping domains of functionality. You want these to be distinct so that it's easy to figure out the code you want there and there's no question about it. So you don't merely want a proliferation of semi-arbitrary functions in a library, hence a companion rule: ZeroSuperfluousNames. You really want to understand this one for your code? Understand epistemology and ontology.