SitePoint Sponsor

User Tag List

Results 1 to 5 of 5

Hybrid View

  1. #1
    SitePoint Member
    Join Date
    Nov 2009
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Simply Rails 2: passing parameters to methods

    This is less a Rails2 question, and more a Ruby "way" question. It was my understanding that only when you pass multiple parameters to a method should you use parens. However, on p.308 I'm modifying a controller method to accept multiple parameters, and the text indicates the opposite approach:

    Code Ruby:
    #was 
    def index 
      @stories = Story.find(:all)
    end
     
    #changed to
    def index
      @stories = Story.find :all, :order => 'id DESC', :conditions => 'votes_count >= 5'
    end

    When I look at RESTfully generated controllers I see that one parameter method calls are wrapped in parens. My research leads me to believe that the best approach is the one which results in the greatest readability.

    Thoughts?

  2. #2
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My understanding is that Ruby is going towards using parenthesis rather than not. However, at the moment it is a style choice.

    Readability is key. Personally, I think using parenthesis is more precise, which reduces ambiguity, and therefore aids readability. I'm not religious about it, but would tend toward using them rather than not.

    BTW
    Code:
    :conditions => 'votes_count >= 5'
    Is the best way of forming a conditional statement. This would be better (with parenthesis ).
    Code:
    def index
      @stories = Story.find(:all, :order => 'id DESC', :conditions => ["votes_count >= ?", 5])
    end

  3. #3
    SitePoint Member
    Join Date
    Nov 2009
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ReggieB View Post
    Is the best way of forming a conditional statement. This would be better (with parenthesis ).
    Code:
    def index
      @stories = Story.find(:all, :order => 'id DESC', :conditions => ["votes_count >= ?", 5])
    end
    Why would I ask for string interpolation in the conditions statement when the value of 5 is clearly known? This syntax adds bloat in the statement, and asks the interpreter to do something unnecessary (parse the string and replace the ? with a 5).

  4. #4
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Because it does more than parse the statement. It also gets validated to prevent SQL injection and help format the statement correctly. Have a look at the conditions section in the API documentation:

    http://api.rubyonrails.org/classes/A...cord/Base.html

    If the number is never going to change and is hard coded, then your original format is OK. However, my experience is that these things often start as hard coded, but later get turned into variables. If you start with the safer format then simply replacing the hardcoded value with a variable will be relatively safe. If you use your original format, you have to ensure you or the person making the change also change the query format.

    In my experience it is always better to get into the habit of using best practice and only to move away from that if there is a very good reason to do so.

  5. #5
    SitePoint Member
    Join Date
    Nov 2009
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ReggieB, thanks for your explanation. When I referred to the documentation you suggested, it supports my original assertation:

    Conditions can either be specified as a string, array, or hash representing the WHERE-part of an SQL statement. The array form is to be used when the condition input is tainted and requires sanitization. The string form can be used for statements that don‘t involve tainted data.

    We should be very wary of premature optimization in a language like Ruby, and a framework like Rails. This is because both are low ceremony, low viscosity. This means that in Ruby/Rails it is easy to do the right thing. We should follow both best practices here:

    1. Sanitize dynamic data that is used to form dynamic sql.
    2. Avoid premature optimization.

    Finally, we should be writing test cases for sql injection so that we are aware of any development practices that aren't in line with best practices.

    Again, thanks for your comments.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •