(Or, I Never Met a Class I Didn't Dislike)
This entry attempts to document a programming paradigm I call Anal Programming (AP). AP represents nothing "new" in the way of programming design or theory, introduces no new buzzwords or acronyms (beyond AP), uses no fancy procedures or documentation, nor requires any adherence to any particular "style". AP is simply writing code in as straight forward a manner as possible with an emphasis on the combination of three universal aspects of programming:
The first thing to note about AP is that the three aspects must be taken (and used) together, in that code that is efficient but not comprehensible is not Anal. Code that is very efficient and extremely comprehensible would be an abject failure if it is not also versatile (as these terms are defined within the aspect of Anal Programming).
The Definitions of the three "Universalities"
Efficiency -- in the case of AP -- is not to be confused with minimumality, i.e. it is not simply least number of machine cycles, characters or number of lines. Efficiency, here, is all encompassing -- which is why, but not solely, it comes first in the list. Efficiency is the sum of the code taken in "block" size pieces and is a measure of code quality in the context of versatility and comprehensability. Efficiency is recursive but does not require recursion.
Versatility is a measure of how useful the code is as well as how easy it is to use the code and as well how easy it is for the code to be used. This last aspect -- "for the code to be used" -- is not a trite euphemism, but a requirement of Anal Programming. This triad of use -- Usefulness, Usage and Use -- will require more definition. Usefulness is self-explanatory; code that does something measurably useful to you. Usage is a measure of access, installation, configuration, modification, editing, and requirements. Use is the interface, the API, or even just the function list; think of this use as the programmer's use of the code. In larger abstract terms, one can think of PERL and PHP as Versatile programming languages in this regard as they generally meet all three elements of these definitions of "use". (PERL: "There is more than one way to do it." AP: "There should be enough ways to do it.")
Comprehension is last in the list because one might almost think of the formula Efficient + Versatile = Comprehsible. However, if one spends all his/her time and effort on efficiency (as the least amount of characters and expressions and blocks) and versatility (as complex classes, function overloading, etc) one can easy produce non-comprehensible code. In fact, it is all to easy to produce non-comprehensible code. Ideal comprehension means understanding at a glance. Though it can be difficult to achieve, it is hardly impossible. By working with E + V = C in mind one will find that producing Comprehension is achievable when Efficiency is combined with Versatility.
Where Anal Programming Fits with Regard to other Programming Paradigms
Sometimes someone needs to dash off some code to "scratch and itch". In that case, that someone should do what ever he or she wants to do to accomplish the goal. One would not use AP just to fix something.
Sometimes someone needs to adhere to an existing paradigm -- a driver, an extension of a class or library, and extension of a language, an add-on (or add-in) to an existing program. In all those cases one would not use AP.
AP is a discipline. AP is a discipline based upon practicality (and perhaps even pragmatism).
One would not use AP with OOP.
UML is the antithesis of AP.
The Drawbacks of Anal Programming
Before I get into actual coding and programming practices I must mention that achieving all three of the aspects defined above comes at a price: a lot of work. One must be willing, for AP requires it, to constantly re-think, re-examine and re-write his or her code. In fact, it might be that early purveyors of AP will be re-writing most of the time as old programming practices will get in the way (more on this later in "Actual AP Coding and Programming Practices").
Within the AP paradigm one would not hesitate to completely re-implement something -- the format of a configuration file for example -- right in the middle of a project, if in doing so would decrease complexity and increase either efficiency or versatility. One would do so even if the reduction would be just one global variable.**
Within the AP paradigm one would not simply choose one database (unless one had to for reasons mentioned in "Where Anal Programming Fits with Regard to other Programming Paradigms"), but would code so that ANY database could be used.***
Simply put, AP is a lot of work.
Actual AP Coding and Programming Practices
Before starting out on a road to Anal Programming one would have to throw away, forget, vanquish, utterly annihilate all high-falutin concepts such as "Reusability" and "Oriented" and "Elements" and "Patterns". One would never write "anchored exception declarations to solve problems with checked exceptions and reusable software elements" within the AP paradigm. One must remove one's "pre-programming" when implementing as AP. There is only one thing of utmost importance in AP - efficient, versatile and comprehensible code.
Here is a small example of an AP program. PHP Form Handler. (It is, as most AP projects, not finished and parts will be re-implemented at a later date.)
[END PART ONE -- MORE HERE LATER -- NOT FINISHED]
* In this preliminary post I leave out the critical examination of the example. A critical examination and analysis will, of course, be required. Perhaps I can finish this essay with a few months.
** I will concede already that AP would never be adopted in a corporate setting.
*** Within the AP paradigm one would not hesitate to have an "encapsulation of an encapsulation" to achieve this.