Slashdot Mirror
Reusing and Recycling Code
An anonymous reader sends us to a writeup about when and how to recycle code, excerpting:
"As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind's phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects....Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don't work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs. "
If you think about how much energy is needed to produce (good) code, recycling it will also help to save the environment!
Seriously!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
To quote from the fine article itself:
My psychic abilities tell me you're wondering why this wall of text was worth your time. It probably wasn't.
What he talks about in terms of PHP is precisely what Lisp macros are about: you identify common patterns in your code, and then you generally break the patterns into a couple of short, generic functions and a macro, or sometimes, just a macro will do.
In any other language you build a library of functions, classes, etc. to do the common things that you want to reuse.
The above applies to PHP as well. It has the include filename construct for a reason.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
That's quite a rant on programming for a Javascript form field validator.
The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like this one for a credit card number: />
<input type="text" pattern="[0-9]{16}" name="cc"
If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.
For some reason, the WebForms proposal made very slow progress and never caught on.