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