From the Wikipedia link you provide - "modularity is the degree to which a system's components may be separated and recombined"
Lines of code != system's components.
It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
This is itself backed by the wikipedia link, 'In software design, modularity refers to a logical partitioning of the "software design" that allows complex software to be manageable for the purpose of implementation and maintenance. The logic of partitioning may be based on related functions, implementation considerations, data links, or other criteria'; what we have done by splitting up the code this way has not helped it be more manageable.
So no, by the definitions you yourself cited, splitting up the code does not translate to more modular code.
Did I say this? No. Does this have anything to do with the conversation? No.
>It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
You think of logic as procedural lines of instructions. Procedural lines of instructions are not modular. If you think like this, none of your code is ever truly really modular. All code should be writable in one line. You split into several lines ONLY for readability, but your core logic should easily be isomorphic to one line code.
If your code doesn't share this isomorphism then none of your code is modular.
Inevitably you have to eventually address the procedural nature of the world in your code. When this case arises you have to abstract this all away to the smallest section of your code as possible.
>what we have done by splitting up the code this way has not helped it be more manageable.
Modularity and Manageability ARE TWO different words with two different definitions.
Wikipedia in this case is just being dumb and fuzzy with it's definitions. Right above your cited link it has an alternative definition that is in direct conflict with the one you stated. Modularity in modular programming is different from modularity in software? Come on. This is stupid.
Let's not play pedantic games here. Modularity and Managability are different. We know this. No need to play games. Combining the two into one thing is a lack of coherence. Be coherent.
When you take one thing and split it into two things. The two things are modules and thus more modular than the one thing. That is simple intuitive and clear.
Lines of code != system's components.
It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
This is itself backed by the wikipedia link, 'In software design, modularity refers to a logical partitioning of the "software design" that allows complex software to be manageable for the purpose of implementation and maintenance. The logic of partitioning may be based on related functions, implementation considerations, data links, or other criteria'; what we have done by splitting up the code this way has not helped it be more manageable.
So no, by the definitions you yourself cited, splitting up the code does not translate to more modular code.