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. "

Comments

Re:Pontification

[Anonymous Coward]

First off your example is flawed. Not only can credit card numbers be 13-16 characters - CC type validation is useless without applying the mod10 check algorithm to the field.

My point is while there is utility in pattern matching via regular expressions webForms themselves won't solve everything and you can largly solve the problem already with a dizzying array of javascript validation functions freely avaliable online which essentially do the same thing on all browsers today.

For example instead of extending base language one could very easily write a javascript function that accepted the input parameters...

validateField('cc','\d{16}');

Another problem is that you also need to implement server side validation so many people either ignore client side alltogeather or have a system for exposing the same internal validation rules to the web form automatically which lends itself more to a programatic/javascript approach than a prescribed web-forms approach which *still* requires javascript for full coverage.

I'm a **huge fan** of domain specific languages and using the right tool for the right job... however sometimes too much specialization can be a bad thing. In this user case choice trumps prescribed technology implementation.

I would also jokingly argue making form based validation too easy only encourages the less experienced to shrug off the need for server side validation.