What is the official position on the DRY concept in Rails?

rubyonrails-docs
1

I have a question about the DRY (Don’t Repeat Yourself) principle in Rails.

According to the Rails Guides, DRY is on of the major guiding principles of Rails.

However, in The Rails Doctrine by DHH, DRY is not mentioned at all. It seems that DHH thinks DRY is not so important in Rails.

I believe the two documents are both official, so I am wondering why such disagreement is occurring. What is the official position on the DRY concept in Rails?

1 Like
2

Very hard to make canonical rules re: DRY. I can’t speak for DHH, or anyone else for that matter. However let us consider whether DRY is, or is not important?

Rails is foundationally based on extracting common patterns so that we all don’t have to repeat ourselves. It’s super important. Rails also sets appropriate defaults for us so that we don’t get overwhelmed by 1000s of tedious decisions that don’t really matter. e.g. should a primary key column be named: ‘id’ or “Id” (capitalised).

Sometimes in your code base, when making a decision to repeat vs not repeating: there are always costs and benefits. Sometimes the costs outweigh the benefits, and vice versa. If you want an authoritative source, consider why DHH says: “no one paradigm”.

I’d say the same: do what works for you. Worst case scenario: you make a bad decision. That’s ok. You can go back and revert. You learn as you go.

2 Likes
3

Thanks for the reply!

Sometimes in your code base, when making a decision to repeat vs not repeating: there are always costs and benefits.

I completely understand and agree to the point.
My question is, if that is the case, why should DRY be a principle of Rails?

In my understanding, DRY is a general principle of programming. It is not only for Rails. You can choose to repeat your code or not when writing Rails.
(On the other hand, CoC is unique to Rails and you must follow the convention when writing Rails. So it is natural to be a principle of Rails, I think.)

I am wondering if there is a special reason for Rails to keep codes much more DRY when compared with other frameworks.

1 Like
4

Not sure what’s the point, but here my $0.02.

We build the ecosystem together but people do whatever they want with Rails.
There are no official positions on anything, just people’s opinions. The official document is not official in the sense that there is no one true or opinionated way to do things; the community, which consists of many individuals, helps write it together.

DHH is just cool with it. His company uses yarn, but if someone wants to use npm, cool, just send us a pull request.

Rails code looks much more DRY than other frameworks because of Ruby. I can’t see other languages beating Ruby in this regard.

For me, I use Rails a lot as a collection of libraries.
I don’t use ActiveRecord; I don’t use MVC pattern; I choose a vanilla webpack with propshaft for my frontend; disable several rubocop rules; turns my back to both conventions and configurations.

And that’s fine; I feel more productive than following everything people say.
And I am cool when people don’t think the way I think. That’s how we thrive as a community, and Ruby made these things possible; in disagreement, we abstract and let everyone have their way.

When you have no idea, you could try other people’s opinions and see where it goes; when you have yours, you can disregard anything written on the official document. See where your opinion takes you.

2 Likes
5

Maybe DHH didn’t want to repeat himself :laughing:

More practically I don’t think the absence of “DRY” in the doctrine means Rails is anti-DRY. I wouldn’t read into it too much.

2 Likes
6

Thank you for very interesting comments!

As a background of my question, I was thinking that there should be a single authority that stipulates the principles of Rails, for example, whether Rails is DRY or not.

After reading your comments, I understand that the authority is not necessarily needed or not so important. Rails doesn’t belongs to the authority, but to the community. Each Rails engineer can their own opinions. It seems to be a good idea. At least Rails community is managed as such.

2 Likes
7

DRY is not exclusive to Rails; it’s a programming principle.

Also, it’s not an absolute; there’s no black or white. Choosing the right shade of gray is a skill acquired over time. At first glance, one might think that the drier the code, the better it is. However, drying code involves creating abstractions, and creating poor abstractions can be much worse than having some lines of code repeated in a few files.

It’s also important to remember that DRY isn’t about typing less code but about concepts that will evolve together. Just because two files contain similar code doesn’t mean they will remain the same indefinitely.

This article explains it much better than me:

1 Like
8

Some context from when Rails was created may be helpful. There were two main ways to do web development: PHP and Java Enterprise Edition (J2EE or JEE). In Java, the popular ORM tool Hibernate required you to do do three things to map a column to an object’s property:

  1. Create the column in the database (Hibernate had no concept of migrations at the time)
  2. Declare a property in your class (which in Java usually meant a private instance variable e.g. private String name; and a getter getName() and a setter setName(String name)
  3. Add either XML configuration or an annotation to the source file to indicate that the column created in step 1 would map to the property created in step 2

I can tell from experience, it was really tiring to tell Hibernate and Java that yes, the name field of the users table should be mapped to the name property of the User class. Rails was a breath of fresh air because you did not have to do this - you didn’t have to repeat yourself.

I think the way this shows up in the Rails Doctrine is “convention over configuration”, and even though I don’t know DHH at all, I am almost certain he still finds convention over configuration extremely important to Rails.

2 Likes