Last week, while developing a feature I had some code like this in a view:

link_to_unless @post.url.blank?, "Link to post", @post.url

Where url is an attribute of type String. As people usually don’t like negative conditionals, we can easily rewrite this code as:

link_to_if @post.url.present?, "Link to post", @post.url

However, we can clean our code a little bit using the #{attribute}? method.

link_to_if @post.url?, "Link to post", @post.url

The #{attribute}? method is a method defined automatically by Active Record. Intuitively, you may think that it is equivalent to !!url and then would evaluate to true when an empty string, but Rails is smart enough to detect that the attribute is a string and returns the equivalent of !url.blank?, as you may see in these lines in Rails source code, which proved itself very useful.

Active Record defines many other attribute methods like that, for example url_changed?. What about you? What is your favorite Rails attribute method?

I tend to favor clear code over concise code, and here `@post.url.present?` feels more clear to me than `@post.url?`. If it’s a boolean attribute on the other hand, I’m all for the query method.

rlmflores

You have a point :). When developing an application, we should always measure conciseness over clarity.

But as this method is not widely used, it is not clear what it does, but maybe after getting used to it we may have it clear (like when we use [] instead of Array.new). I like to say that it is some kind of sugar (and Rails is full of sugars) to create beautiful code 🙂

sameera207

+1 for the clear codes. Specially with a dynamic language like ruby I think we should always try to write clear codes. When I say clear, what I meant is that method names should implies what it does.

Well, of course we have a conflict. A conflict among principles! @post.url.present? might seem clearer than @post.url? And it is.
On the other hand, @post.url.present? seems to be a violation of the law of Demeter, which is more than a trivial “too many dots” rule at the end of the day. And it is.The solution to both concerns, might best be rendered thus: @post.url_present? Clearer and no Demeter violation. On the other hand, it seems a pain to be typing all of those ourselves, suggesting perhaps a change to the Rails structure, or at least, a concession to clarity for the sake of what we know to be a Rails convention. Leading finally to the possibility that yet another OO design issue is presented — that of not using the persistence layer itself as though it were the domain object. Since it is highly unlikely that each and every attribute will be .present?-tested, perhaps if we simply entered these only on an as-needed basis to a distinct domain-object as part of our TDD then rely on automagic? I leave these disputes to those more expert than I.Still, the more I read these nuanced discussions these days, the more I think that the DDD contingent may have it right, that this kind of logic really does belong at the end of the day in distinct business objects, which objects ultimately are used in connection with ActiveRecord through an architecture layer as a thin veneer over the database.Just saying.

Dennis Monsewicz

I am certainly in favor of all things Ruby/Rails. I also believe that things like this becomes an issue of choice. Whether you use `@post.url.present?` or `@post.url?` is simply up to the programmer. I think using `@post.url.present?` will bode better results if someone comes in behind you to do some programming.