Hello,
See here:
www.open-std.org/.../C99RationaleV5.10.pdf
Is it possible that "Jack Sprat", the staunch defender of the C standard as the ultimate reference when writing programs, missed the following statement?
C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler”: the ability to write machine- 35 specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§4).
this is precisely what Per Westermark has been saying. Exactly what Erik Malund has been saying. Remember: Jack Sprat claims often that writing a program that complies with the C standard is a GUARANTEE for its correct functioning.
"... reducing the cohesion and data coupling."
Or:
"... increasing the cohesion and data coupling."
Either way, "someone" needs to get a clue about "proposing an idea/rule".
"multi-layered structure of software design leads to more depth of function calls and more RAM consumption"
Yes: like use of the programming langugage, use of a "multi-layered structure" can be done well, or done badly - it is not, of itself, a magic bullet.
Yes: adding an "abstraction" layer to help make code portable does usually add some overhead. As always, there is a tradeoff of the gain in terms of developer/maintainer performance against any overheads on the target.
The criteria for "optimisation" need to include not only the "costs" of code size, RAM size, and execution speed - but also the developer/maintainer costs...
It is not uncommon that different parts of the code will need different balances in this tradeoff...
Writing modular code is something that is done to help reduce the complexity and/or improving code reuse.
That obviously requires a very light hand. Prio 1 is to analyze the situation. Then a suitable solutino can be suggested.
That means that a company can't just produce a document telling how people should modularize a program. The process must include the project team based on the needs of the project and the available resources.
Having iron-hard rules doesn't help the project team - except that they are allowed to turn off their brains and hack lousy "by-the-book" code without having to care about how well it works. The goal should be to write economical and well-working code, not a 25-layer precursor to Eddie, the shipboard computer from The Hitchhikers Guide to the Galaxy. It just may end up more like HAL from 2001.
Is that the latest Arduino spin-off...?!
;-)
"Writing modular code is something that is done to help reduce the complexity and/or improving code reuse."
in my case, it is primarily to reduce labor cost and reduce time to market, by providing high quality code that has been debugged before.
it is, from that point of view, a preservation / institutionalization of our prior investment in debugging.