The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

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:

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.

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 ).

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).

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.

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.