a95985c0a08ef9fc7893…

I appreciate your last paragraph the most, I think that sums up my opinion the most and I whole-heartedly agree. That is what I have an issue with, it doesn’t express anything as a simple letter doesn’t necessarily mean anything, unless you look at the context. On one argument, it’s standard and most people know that f represents a form.

Saying that, I am not opposed to something like i for index. Maybe because I’ve ALWAYS known it to be that, and it’s not just Ruby that does it.

@Ben: Hang your head in shame! Actually, that code makes a good argument for using form throughout, that way, when you extract a chunk of code into a partial (which you will, inevitably, call form, you can magically pass it an appropriately named local variable by doing render :partial => 'form', :object => 'form'. Obviously, any subsequent partials will need a :locals hash, but I’m not sure that happens as often.

@Zach: Use of abbreviations doesn’t have to be a slippery slope: the folks who slide down it would probably slide down some other slope anyway.

The key question anyone should ask themselves of their code is “Does this express my intention clearly”, sometimes a judiciously chosen abbreviation helps, at other times it hinders.

As for the overuse of abbreviations in general, that’s another blog post. But I never avoid a good practice because it can (theoretically) lead to a bad practice.

///ark

F is not an awful abbreviation but I seem to find that once people start abbreviating often, their code gets sloppy and they abbreviate too often. Also, you only know what f when you know the code, which seems anti-Ruby to me. Ruby was always meant that you could just pick up a document and read it to know what it does. I personally use make instead of f for forms. It makes more sense in my mind.

Ben has the perfect example of what I mean, and to me it feels like the Rails Core code is littered with those examples.

<%= render :partial => ‘form’, :locals => {:f => f} %>

I weep for the state of the world, with people (like me) who write this in it.

In form_for’s case, f doesn’t seem like an awful choice, though I suppose there’s a case for form, otherwise the same rule applies - if the body of the form gets complicated enough that you want a more meaningful name for it, use a partial and pass f in as its :object.

In the Hpricot example, I’d be more inclined to use it, or possibly each, but mileage varies.

The rule of thumb is to standardize on particular parameter names in blocks of different points and, when you start to feel the pain of not having a descriptive parameter name, extract a method and give that a meaningful parameter name (or, better, make it a method of f’s class if you can).