maps

I do this through maps.  I map is fairly simple to setup in vim.

:map ,cs <ESC>:w\|:!phpcs --standard=myYearbook %:p

Typing that into a vim instance means I can type ‘,cs’ in normal mode, and vim will w my file to disk, then run phpcs using the myYearbook standard on the current file I’m working in.  Now, I use that often enough that I’ve added it to my .vimrc file.

map <Leader>cs <ESC>:w\|:!phpcs --standard=myYearbook %:p

If you aren’t aware, <Leader> is set to ‘,’ using this bit of code in .vimrc:

let mapleader = ","

The comma is popular, but you can use whatever you want, really.

I can also pack my javascript and CSS files with similar ease using “,pj” and “,pc” (pack javascript, and pack css).

map <Leader>pj <ESC>:!jspack %:p > %:p:h/%:r:r.js
map <Leader>pc <ESC>:!csspack %:p > %:p:h/%:r:r.css

You might be wondering what the ‘%:p’ part is.  It’s actually part of the expand functionality of vim.  Basically, the important parts here to understand is that the % is the current file name.  The “:p” and “:r” parts are the modifiers.  In this case, “%:p” has us expand to the full path.  The “:h” modifier removes the last component.  So, “%:p:h” basically says “Give us the full path, and then remove the head.  The head in this case is the file name, so if the full path (“%:p”) is /Users/jasonlotito/test.php, “%:p:h” gives us “/Users/jasonlotito”.

“%:p:h/%:r:r.js” allows me to rename my file.  In our setup, unpacked files contain the extension “.unpack.”  By Simply using the “:r:r” modifiers, I strip off the “.js”, and then the “.unpack”, leaving me with just the file name.  So, if my javascript file was named Modifiers.unpack.js, I’d be left with Modifiers.  I prefix that with %:p:h/ which gives me the directory the file is in, and append “.css” to the path.

Being able to map commonly performed actions, especially to external tools, means I can stay in vim longer.  Sure, I’ll still background vim when I need to perform certain actions, but I’m more apt to start scripting repeated actions, and then mapping them.

I cannot fathom how anyone can honestly think this is good and want to encourage its use.

<?php
return array(
// lots of config stuff here
 
            /**
             * Routes
             */
 
            'ZendMvcRouterRouteStack' => array(
                'parameters' => array(
                    'routes' => array(
                        'zfcuser' => array(
                            'type' => 'Literal',
                            'priority' => 1000,
                            'options' => array(
                                'route' => '/user',
                                'defaults' => array(
                                    'controller' => 'zfcuser',
                                    'action'     => 'index',
                                ),
                            ),
                            'may_terminate' => true,
                            'child_routes' => array(
                                'login' => array(
                                    'type' => 'Literal',
                                    'options' => array(
                                        'route' => '/login',
                                        'defaults' => array(
                                            'controller' => 'zfcuser',
                                            'action'     => 'login',
                                        ),
                                    ),
                                ),
 
// more config stuff here
);

Don’t Repeat Yourself

The problem here is two-fold.  First, I was looking for how to replicate actions I would perform in other editors. Saving a file, editing text, copy and paste, search and replace: all these things easily map to something you’d do in a traditional IDE.  You don’t replace a character in a traditional IDE.  You delete a character and enter a new one.  To copy and paste big blocks of text, you highlight that text with a mouse.  You navigate to different tabs with your mouse.  When you want to split your window, you probably have to do so with the menu.  You don’t append to a line.  You simply move your cursor and start typing.  You don’t jump to a character, and while you can, you rarely jump to a line.  You aren’t yanking lines, you don’t concern yourself with buffers, and you don’t repeat your actions.

Basically, an IDE more closely resembles a word processor for programming languages, whereas vi is a completely different beast (vi vi vi, editor of the beast, after all).

Therefore, the first thing I had to understand before really learning vi was I had to look past replacing what I did with an IDE, but rather, understand how to do things in vi.  And this is a fairly easy concept to understand once you learn one of the defining principles of using vi: if you have to keep pressing the same key to do something, you are probably doing it wrong.  Consider the basic movement keys: hjkl.  Using ‘j’ and ‘k’ to move more than one line should indicate to you there is a better way.  Moving to the top of the screen, the bottom, the middle, move up a page, half a page, or down.  These aren’t things you do in an IDE (you scroll), but in vi, that is an essential piece to the puzzle.

So, every time I wanted to do something, and I found myself repeating actions that seemed awkward, I’d search for a way to do it.

Find out more about noticing and unlearning vi anti-patterns with this excellent article from Tom Ryder.

Learn the Language

This leads us to the second thing I had to understand in order to really being learning vi.  You don’t learn vi by learning commands, you learn vi by learning a language.  Once you have a firm grasp of the language, you can start putting together your own commands.  Discovering new commands seems to become more intuitive.

Lets see this language in action.  Normally, if you want to delete a line, you’d type ‘dd’.  This deletes the line (and stores it away so you can paste it later if you want).  What if you want to delete more than one line?  You could repeat ‘dd’ on each line you wanted deleted.  But let’s say you want to delete the next 10 lines.    This is where the language comes in.  What you want is to delete 10 lines down.  So, you start with ‘d’, then enter 10, and finally, ‘j’ for:

d10j

This isn’t so much a command you need to remember.  Rather, it’s easier if you understand the language.  Deleting 5 lines up can be constructed the same way:

d5k

Once we learn how this language works, we can create our own commands

‘==’ will indent the current line.  We can follow the same pattern as delete to construct the following:

=5j

This properly indents the next 5 lines.  Of course, we can also do ‘gg=G’, which will move you to the first line, and then indent all lines until the last line.  We can do ‘ggdG’ as well, which will delete all the lines in the file.

The actual commands aren’t important.  Rather, it’s the language.  Once you understand how ‘d’ works, you can use the same language in other areas as well.

Want to copy the next five lines?  Just knowing that ‘yy’ will copy the current line, you could easily discern that ‘y5k’ will yank (copy) 5 lines up.

You can learn about speaking the vi language by reading an excellent article from Yan Pritzker.

Investment of time

Yes, learning vi will take time. It’s not something that will come naturally.  It’s a tool, and like any powerful tool, you have a lot to learn to truly start taking advantage of it.  It’s a professionals tool.  It’s a craftsman’s tool.  It’s something that, regardless of whatever else you might learn, will benefit you as long as you are programming.

Sure, you might enjoy your IDE, and I’m not here to suggest you drop your favorite tools.  Rather, it’s worth the investment to understand vi, it’s language, and how it works.  Even if you aren’t using it every single day, you’ll appreciate being able to open up the editor and using it without feeling constrained.

Other Resources

• VIM University
• VIM Casts
• Learn to speak vim

1. Do one thing.
2. Do it well.
3. Keep it concise.
4. Use only what is given.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

public function createAction()
{
    $adminForm = new Form_User();
    $adminForm->removeElement('dealership_id');
 
    if ($this->getRequest()->isPost()) {
        if ($adminForm->isValid($_POST)) {
            $mAdmin = new Application_Model_DbTable_Users();
            $result = $mAdmin->createAdmin(
                $adminForm->getValue('name'),
                $adminForm->getValue('email'),
                $adminForm->getValue('password'),
                $adminForm->getValue('role')
            );
 
            if ($adminForm->getValue('notify') === 'yes') {
                if ($adminForm->getValue('notifyPhone') === 'yes') {
                    $notification = new Application_Model_DbTable_PhoneNotification($mAdmin);
                } else {
                    $notification = new Application_Model_DbTable_Notification($mAdmin);
                }
                $notification->sendNotification();
            }
 
            if ($result)
                $this->_forward ('confirm');
        }
    }
 
    $adminForm->setAction('/admin/create');
    $adminForm->setMethod('post');
    $this->view->form = $adminForm;
}

Before we start refactoring this, I want to cover a couple things.  First, the above is a small example, but it can still be used to explain our need.  Secondly, what we learn here can be applied to code, regardless of the size or complexity.

Complexity

Before we set out on this road, we need to define complexity.  Specifically, I’m referring to Cyclomatic Complexity.  The best definition of Cyclomatic Complexity that I’ve found is from the PHPMD page on Cyclomatic Complexity.

Complexity is determined by the number of decision points in a method plus one for the method entry. The decision points are ‘if’, ‘while’, ‘for’, and ‘case labels’. Generally, 1-4 is low complexity, 5-7 indicates moderate complexity, 8-10 is high complexity, and 11+ is very high complexity.

Our goal is to keep what we write in the low complexity category.  At this point, we should go through the sample code from above, and figure out how much complexity there is.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

public function createAction()  // Complexity 1
{
    $adminForm = new Form_User();
    $adminForm->removeElement('dealership_id');
 
    if ($this->getRequest()->isPost()) {  // Complexity 2
        if ($adminForm->isValid($_POST)) {  // Complexity 3
            $mAdmin = new Application_Model_DbTable_Users();
            $result = $mAdmin->createAdmin(
                $adminForm->getValue('name'),
                $adminForm->getValue('email'),
                $adminForm->getValue('password'),
                $adminForm->getValue('role')
            );
 
            if ($adminForm->getValue('notify') === 'yes') {  // Complexity 4
                if ($adminForm->getValue('notifyPhone') === 'yes') {  // Complexity 5
                    $notification = new Application_Model_DbTable_PhoneNotification($mAdmin);
                } else {  // Complexity 6
                    $notification = new Application_Model_DbTable_Notification($mAdmin);
                }
                $notification->sendNotification();
            }
 
            if ($result)  // Complexity 7
                $this->_forward ('confirm');
        }
    }
 
    $adminForm->setAction('/admin/create');
    $adminForm->setMethod('post');
    $this->view->form = $adminForm;
}

A total of 7 complexity, on the high end of moderate complexity.  You might be looking at this code and wondering what makes it so complex.  It is simple enough.  It’s built to handle a form.  It checks input, creates a new user if the form was submitted in a valid format, and sets up notifications that were obviously a choice in the form.  It finally forwards off to the confirmation.

But, that is actually a lot of complexity.  To test this function, we’d need at least 7 test cases.  Even more so, this method violates some of our rules.  Do one thing.  It does many.  It’s not concise.  And it’s also not just using what is given.

We are going to focus on the complexity portion today.  We are going to bring down the size of this method step by step.

Indents are intents to modularize

Every time you indent your code, you should be thinking about modularizing.  In other words, if you indent your code into a block, you should consider moving that code into it’s own method.

Let’s start with the extremely large if in the middle there.  The one that checks to see if the request is a post.  When we indent that block of code inside, we should ask ourselves if that code inside can be better moved to it’s own method.  The answer is a resounding yes.  Within that block of code, we have 5 levels of complexity.  By moving all that complexity out of the createAction method, we will help decrease the complexity of that single method.  More so, we make that method easier to read, and we are able to compartmentalize the code even more.  We make our code even more reusable.

Where with comments we used the comment as an indicator of a new method, here we use the ideated block of code as an indicator.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

public function createAction() // Complexity 1
{
    $adminForm = new Form_User();
    $adminForm->removeElement('dealership_id');
 
    if ($this->getRequest()->isPost()) { // Complexity 2
        $this->letFormHandleInput($adminForm);
    }
 
    $adminForm->setAction('/admin/create');
    $adminForm->setMethod('post');
    $this->view->form = $adminForm;
}
 
protected function letFormHandleInput ($adminForm) // Complexity 1
{
    if ($adminForm->isValid($_POST)) { // Complexity 2
 
        $mAdmin = new Application_Model_DbTable_Users();
        $result = $mAdmin->createAdmin(
            $adminForm->getValue('name'),
            $adminForm->getValue('email'),
            $adminForm->getValue('password'),
            $adminForm->getValue('role')
        );
 
        if ($adminForm->getValue('notify') === 'yes') { // Complexity 3
            if ($adminForm->getValue('notifyPhone') === 'yes') { // Complexity 4
                $notification = new Application_Model_DbTable_PhoneNotification($mAdmin);
            } else { // Complexity 5
                $notification = new Application_Model_DbTable_Notification($mAdmin);
            }
 
            $notification->sendNotification();
        }
 
        if ($result) // Complexity 6
            $this->_forward('confirm');
    }
}

Referring back to createAction, we see that the complexity has dropped to a mere 2 points.  Granted, letFormHandleInput is 6 points, but we aren’t done yet.  Each method should be easy to understand, and easy to test.  createAction is now incredibly easy to understand.  It creates a new form for display, and if it receives a post request, it let’s the form handle the input.

I’ll admit, I’m not too enamoured with the name of the new method, but it’s simple, and defines exactly what the method does.  More importantly, we’re also passing the form in.  This means that we can pass this method any form.  If something fails, we come out of the method, and continue with the display of the form.  Normally, I’d want to also define letFormhandleInput as

protected function letFormHandleInput(Zend_Validate_Interface $adminForm, array $data)

Here, $adminForm would be explicit in what it is, and I’d pass in the $_POST data, rather than calling it.  In the method itself, I’d swap out the calls to $adminForm->getValue, and instead call directly from $data.  However, this goes beyond our discussion here.  However, I make mention of this because those simple changes are not only easy to make, but value in terms of maintainability, testing, and longevity.

Because letFormHandleInput is still complex, we need to extract some methods out from it as well.  letFormHandleInput is actually wrapped directly around a giant if.  A simple check to see if the $_POST data is valid.  After that point, everything is indented. It also happens that the form doesn’t do much after that.  We grab data from it, but as I noted above, that’s easily removed. Regardless, the sign is fairly clear: indented blocks are what we are looking for.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

public function createAction() // Complexity 1
{
    $adminForm = new Form_User();
 
    $adminForm->removeElement('dealership_id');
 
    if ($this->getRequest()->isPost()) { // Complexity 2
      $this->validateNewUserDataInput($adminForm, $_POST);
    }
 
    $adminForm->setAction('/admin/create');
    $adminForm->setMethod('post');
    $this->view->form = $adminForm;
}
 
protected function validateNewUserDataInput (Zend_Validate_Interface $adminForm, $data)  // Complexity 1
{
    if ($adminForm->isValid($data)) { // Complexity 2
        $this->addNewUser($data);
    }
}
 
protected function addNewUser ($data)  // Complexity 1
{
    $mAdmin = new Application_Model_DbTable_Users();
    $result = $mAdmin->createAdmin(
        $data['name'],
        $data['email'],
        $data['password'],
        $data['role']
    );
 
    if ($data['notify'] === 'yes') {  // Complexity 2
        if ($data['notifyPhone'] === 'yes') {  // Complexity 3
            $notification = new Application_Model_DbTable_PhoneNotification($mAdmin);
        } else { // Complexity 4
            $notification = new Application_Model_DbTable_Notification($mAdmin);
        }
 
        $notification->sendNotification();
    }
 
    if ($result) // Complexity 5
        $this->_forward('confirm');
}

Once again, we’ve reduced complexity, and in our resulting method, our complexity has gone down.  As well, we’ve also remove the task of creating a new user to another method.  addNewUser does exactly that, it adds a new user and all it’s associate baggage.  I also took this time to better define what we needed, and what we didn’t.  You’ll see I’m pulling directly from $data now.  No need to pass $adminForm around.  Also, letFormHandleInput only requires a Zend_Validate_Interface object now, further decoupling ourselves.  I also took the liberty of renaming letFormHandleInput to validateNewUserDataInput.  This name better describes exactly what it does.  Granted, it also goes directly to creating a new user, but that’s something for another day.

Back on topic, lets take the next step, and refactor addNewUser in the same manner we’ve been.  Let’s see, we have another block of code.  This block sets up notifications.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

protected function addNewUser ($data) // Complexity 1
{
    $mAdmin = new Application_Model_DbTable_Users();
    $result = $mAdmin->createAdmin(
        $data['name'],
        $data['email'],
        $data['password'],
        $data['role']
    );
 
    $this->setupNotificationsForUser($data, $mAdmin);
 
    if ($result) // Complexity 2
        $this->_forward('confirm');
}
 
protected function setupNotificationsForUser (array $data, Application_Model_DbTable_Users $mAdmin)  // Complexity 1
{
    if ($data['notify'] === 'yes') { // Complexity 2
        if ($data['notifyPhone'] === 'yes') { // Complexity 3
            $notification = new Application_Model_DbTable_PhoneNotification($mAdmin);
        } else { // Complexity 4
            $notification = new Application_Model_DbTable_Notification($mAdmin);
        }
 
        $notification->sendNotification();
    }
}

In this case, I just decided to encapsulate the entire notification code into it’s own method.  Here now, setupNotificaitonsForUser can be passed proper data, and from that, we can setup notifications for a users outside the creation of a new user.  This means when you write your code for editing a users notification preferences, you already have your notification setup.  Complexity is at 4, but that brings us to the low category of complexity.  There is one more thing we can do to simplify this code.  However, by this point, you should already see what we can do, and how it will simplify the code even further.

By extracting out the second if/else clause in setupNotificationsForUser, we abstract away the creation process.

All these methods can be applied to other forms of blocks of code.  Every case in a switch should probably have its own method.  Any loop should call out to a method.  At every level of complexity, you want to keep things as simple as possible.  When you read a block of code, it should be simple.  It should do something specific.  It should do is quickly, and it should do it well.

1. Do one thing.
2. Do it well.
3. Keep it concise.
4. Use only what is given.

These aren’t overly complex rules. In fact, they are pretty simple. We are going to aim to meet these rules in a rather simple manner: using comments.

Now, let’s define what type of comments I’m referring to. I’m not talking about DocBlock comments. These are comments that allow for parsing by specific tools and allow us to generate documents about the code.

I’m also not referring to comments that repeat the code.

// increment a by 1
$a++;

That is a poor comment, and should be removed. It does nothing except add to confusion.

The comments I’m referring to, however, are a bit more involved. But let’s start with an exercise.

Code should explain what it does. It doesn’t always do this. For example, what’s the purpose of the following code?

if ( preg_match(EMAIL_REGEX, $input) || 
     is_numeric($input) || 
     preg_match(USERNAME_REGEX, $input) ) { /* ... */ }

It’s easy to see what the code is doing, but not the purpose. If we add a comment, it will help matters.

// Check to see if the user input matches one of the searchable data sets
if ( preg_match(EMAIL_REGEX, $input) ||
     is_numeric($input) || 
     preg_match(USERNAME_REGEX, $input) ) { /* ... */ }

Hey! That helps. The code checks to see if the user input matches a pattern for searching a data set. Okay, that helps. But it’s still problematic. The comment isn’t clear. Is it referring to just the if-clause, or is it referring to the block inside the if-statement. Can you trust the comment? After all, as time progresses and code enters maintenance phase, things can and will change. Is it easy to read? It’s not difficult, but when you are read the comment, you then have to mentally associate that with the code. It takes extra effort. And for what? Saying something explicit.

Maybe it’s better that we ask a simple question: What is the comment trying to tell us?

If the input matches a searchable data set, run the blocked code.

Luckily, we can say that succinctly.

if ( $this->inputMatchesSearchableData( $input ) ) { /* ... */ }
 
// ...
function inputMatchesSearchableData ( $input )
{
    return preg_match(EMAIL_REGEX, $input) ||
           is_numeric($input) ||
           preg_match(USERNAME_REGEX, $input);
}

Using the extra method refactoring recipe, we’ve made our code much, much easier to read. inputMatchesSearchableData says exactly what the method does, and in our original block of code, it reads much easier than the comment did. We’ve also refactored the code that checks to see if the input is searchable. We’ve split responsibility, and suddenly, our original method does one less thing.

Every time I use a comment to explain what code is doing, I always ask myself if it’s code that should be removed. If what the code is doing isn’t directly related to the parent method, the answer is most likely yes.

Often times, the comment itself is a good indicator of the name of the function. Extract the method out, and keep each method small, precise, and simple.

To get an invite, an existing member must invite you (and invites only come to those who contribute back to the community), or you have to be voted in after having applied.  To join, you go to the “I want to join” page.  On that page, it asks for a few pieces of information, including a  link to something you’ve done.  A github page, open source project, some fancy design.  Something to show that you are a developer or designer oriented person.

The second part, however, is the most important part.  The Forrst join page asks you to provide sample feedback for a random post.

Provide Good Feedback

Listen.  Forrst is all about communication.  Communication between all types of people.  This means feedback is important.  Poor feedback is bad.  We don’t like it.  However, good feedback is cherished, loved, and rewarded.  So, when Forrst asks you to provide feedback for a post on the Join page, realise that real Forrst members are going to review this feedback.  It takes 3 votes to get you in, and chances of finding 3 people to agree that “That looks awesome” is good feedback is slim.

Let me try to make this clear: the feedback you provide on the join page indicates to us the type of feedback you’ll provide once a member.  If the feedback provided is essentially worthless, then making you a member won’t help the community.  A community built up around feedback.  What this means is that you should put some effort into your feedback.

So, here are some tips on how to write good feedback.

1. Pick a post you can answer

Forrst provides a nice little button that you can click on.  It will reload the post to provide feedback for.  Don’t just settle for the first post you see.  Instead, find something you are actually interested in commenting on.  You aren’t expected to comment on everything that gets posted to Forrst.  Not everyone that gets posted to Forrst is going to get good comments.  So, click a way and find something that will allow you to provide good feedback.

2. Why, not what

“That looks awesome!”

The person you are providing feedback too is probably not going to see your post, so you aren’t going to win brownie points for complimenting work.  Though, if the work is good, providing compliments is fine.

However, in this case, “That looks awesome” is fairly useless.  It just explains what you feel.  It doesn’t explain “why” it looks awesome.  Take a few minutes to go into detail about what you like and why.  Even if you can’t express it clearly, try.  Remember, effort is key here.  Explaining why you like something takes a bit more than just saying you like it, but it provides a lot more value.  Others can learn from it, the original poster can focus on those areas.  Who knows, in explaining why you like something, you might learn a little about yourself.

3. We need Effortmore, not Effortless

Okay, that was bad.  But, the point is, your feedback should take a bit of effort.  It is, after all, an application to join.  And regular members like me are going to read this feedback.  I’ll by frank, if I see a 10 word comment, I don’t bother looking at anything else and move on to the next person.  Maybe it’s unfair, but I figure it’s the same amount of effort put into the comment.

It doesn’t take long.  A couple minutes at most.  Ask yourself after you’ve finished the comment if it’s something you’d like to receive.  Does it actually share a unique idea.  Does it express an opinion? Is that opinion explained?

The Elite

Forrst isn’t about being among the elite.  It’s about being among people who are just like you.  Frankly, if you feel applying to the site and actually putting effort into the feedback is too much work, then Forrst probably won’t benefit you.  That’s fine.  However, if you truly want to join, then maybe this little piece of advice will help you avoid a pitfall you might not think about.  From the Forrst join page:

Since Forrst is a very critique- and discussion-oriented community, we ask prospective users to leave sample feedback on a post from one of our members.

We review this.  The members.  And I imagine those of us that review these potential members are very interested in keeping Forrst’s quality high.  We will be picky.  After all, we want to log into Forrst and enjoy what we read there.  We want to be part of a community of people that we’d go out drinking with.  A little bit of effort will go a long way.

Join us!  We aren’t elitist.  We just want you to know that this is the place for you, and we want to know that you’ll get a lot out of this community.  But only as long as you are willing to give.

Of course, as mentioned, the other way to join is to be invited by an existing member with invites.  Like myself.  In that case, beer is ALWAYS a welcomed bribe.

~/.ssh/config

You simply want to add the following lines to your config file.

Host *
ControlMaster auto
ControlPath ~/.ssh/control_%r@%h:%p

The Host command tells ssh that everything that follows are rules for whatever host is defined.  In this case, the asterisk tells ssh that all hosts should use the conditions present.  ControlMaster enables the sharing of multiple sessions over a single network connection.  ControlPath defines the location the socket connections should be located.  In this case, we are placing them in ~/.ssh/.  %r is token for remote user login, %h is for the host, and %p is the port.  You’ll basically have files that look like this:

~/.ssh/control_username@example.com:22

Brandon Savage posted an interesting article today about how validation blind spots hurt real people.  He gave four succinct rules.

1. Accept valid data in any form provided by the user.
2. Where possible, use well-developed validation libraries.
3. Do not place artificial limits on valid data.
4. Do place valid limits on specific data.

All good advice.  However, it misses out on filtering.  You see, filtering is different from validation.  Filtering is the art of taking bad data and turning it into good data.  It might sound difficult, but it’s actually easier than you think, and will ease the pain in using your software.  Let’s see some examples.

Usernames

Passwords are secret.  Usernames, however, are usually not.  Even if they are private, like an email address, they are usually not the secure part of the application.  Couple this with mobile devices that auto-capitalize, if you’re requiring case-sensitive usernames, you are making things more difficult then they should be for your users.  It’s a pain having to go back, lower case a single letter at the beginning, and then retype a fairly long password just to log in because your site decided that ‘Jasonlotito’ and ‘jasonlotito’ are not the same user.

At the same time, if I do enter my email address, and you ask for a username, then just go with what I give you.  I presume that their is only one email address per account.  If I’ve forgotten my username for your site, but I know I have an email address tied to an account, just let me use that.  You’ve seen I’ve entered my email address, you can then look up by email address, get my username from there, and proceed to validate.

Credit cards

Credit card numbers follow simple rules.  If I enter my credit card number, you know what card I’m using, so asking me is silly.  You don’t even need to know the full number on the card to figure out the card type.  Once I’ve entered enough numbers in for you to know, simply change the pull down to the correct type, and change the icon.  It will give visual feedback that yes, we know what card you are using.  Their is no reason not to do this.

Also, if I put in dashes, or dots, or spaces, or whatever, you can deal with it.  Ignore them.  Simply use the numbers.  You don’t need to exclude characters, simply white list numbers.

While we are here, expiration dates are easy, and yet, somehow, people get them wrong.  Maybe I’m missing out on some details here, but every credit card I’ve ever seen lists expiration dates as MM/YY.  This is a sign that maybe your forms should follow suit.  This means your month should be ’03′, not March (03).  Just ’3′ would suffice.  The year should be equally clear: ’15′, not ’2015′.  I promise you, no one is assuming 1915, or even 2115.

Phone numbers

Filtering phone numbers is hard.  I know.  I’ve had to do it.  The system needed a filtered number because we had to call back in real time from an automated system located in the US.  This mean we needed a properly formatted number that could be dialed.  This isn’t easy, because when you ask for a phone number, people are going to start adding in country codes (but they might).  My suggestion is, unless you are having to do some automated system is to simple not filter numbers unless you can be sure, 100%, of what you are doing.  Even then, you probably don’t need to do it.

Simply ask the user for their phone number, and store whatever they put.  If you need to call them, you can find their country code, or area code if you need to.

Email addresses

Email addresses can be tricky.  You want to make sure they enter in the right email address. A simple mistake can cause problems.  I’ve, on occasion, type in jasonlottio instead of jasonlotito, and the problem was painful to resolve.  On the username side, you can’t do much.  However, after you hit the ampersand, you can start some simple checks.  If someone types in gmail or hotmail or yahoo and leaves off the .com, you can make assumptions.  You can validate these assumptions with the user on the next page.  Transposing letters (htomail) might be something you should look out for, too.  Compile a list of common email providers, and then check how close they are to the users non-common provider name.  If they are close, verify with the user if they didn’t misspell the name.

Assumption

The key to all these filtering techniques is assumption.  It’s not always perfect, but it’s better than failing.  After all, if I’m in Canada, and my phone number is a 10 digit phone number, you can make the assumption that to call me long distance, you’ll need to add a 1.  You can assume that if my credit card number starts with 4111, I’m using a Visa.  Their are lots of assumptions you can make that will make things easier for the user.  Go ahead.  It’s okay.