New to Rails 3? Check out the Ruby on Rails 3 Tutorial book and screencast.

A book and screencast series showing you how to develop and deploy industrial-strength Rails apps in a direct, step by step way. The screencast series includes 12 lessons over more than 15 hours! Get the best "over the shoulder" experience of following what a top Rails 3 developer does when building an app today. Click here to learn more.

20 Things That Suck About Other People's Rails Code

In Miscellaneous, Tips

oohmatron.png Chad Fowler surveyed his Twitter audience and came up with 20 Rails Development No-No's. It makes for entertaining reading.

In short, people hate:

  • Code in views
  • Bad tabbing / spacing indentation
  • Lack of tests
  • Misuse of Single Table Inheritance
  • Poor exception handling
  • Ruby idioms they don't understand
  • Rails idioms they don't understand
  • Poor use of JavaScript
  • Comment overuse

One I don't understand, however, is why "render" is bad. If anyone fancies sending in answers on a postcard..

Support from: Brightbox; - Europe's leading provider of Ruby on Rails hosting. Now with Phusion Passenger support, each Brightbox server comes with access to a managed MySQL cluster and redundant SAN storage. Brightbox also provides managed services for large scale applications and dedicated clusters.

Post to Twitter Tweet This Post

Vaguely Related Posts (Usually)

8 Comment Responses to “20 Things That Suck About Other People's Rails Code”

  1. #1
    Peter Wagenet Says:

    Apparently render is bad because it doesn't use catch/throw? Though I admit that I'm not really sure what that's about either.

  2. #2
    Peter Cooper Says:

    I'm not sure of the original poster's motivations around "render" are, but I do know that render sucks because it no longer ends the processing for that request (like it did pre Rails 1.2?) so you end up with "render :whatever and return" which kinda sucks. Perhaps that's partly what they were getting at.

    Sinatra uses throw/catch for some of its rendering stuff.

  3. #3
    Chad Fowler Says:

    Peter, your followup comment (I believe) nails why Ara doesn't like render. It's not render alone but the render/return idiom.

  4. #4
    Peter Cooper Says:

    I can't remember what the motivation for the change was, but I seem to recall there was one. If I wasn't busy installing Windows 3.11 (don't ask!) I'd try Googling the Rails blog.. might have a look later :)

  5. #5
    Nick Hoffman Says:

    Having to return after a render is a bit dirty, but this doesn't feel so bad:

    return render :foo

  6. #6
    Chad Fowler Says:

    I may be wrong but I don't believe render ever stopped request processing. The change you may be thinking of is when they made the DoubleRenderError a less frequent annoyance.

  7. #7
    Peter Cooper Says:

    Nick: Can't believe I never thought of that.. interesting!

    Chad: You're probably right. When I feel nostalgic I might dust off Rails 0.9.something and see how it still runs - if at all :)

  8. #8
    Peter Wagenet Says:

    I'm pretty sure that this should also work, though I'm too lazy to confirm it at the moment.

    render(:foo) and return

Leave a Reply