Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In Ruby, is there a preference for which level of parentheses to elide, or does it depend on the situation (in which case, what guidelines should be followed)? Sources are appreciated.
For example, is either
do_something do_something_else(...)
or
do_something(do_something_else ...)
better than the other?
You want a rule to decide when to omit parentheses and when not. And that should be based on the method. (It is cumbersome to base the rule depending on the context, i.e., always omit the innermost parentheses, or always omit the outermost parentheses., etc.)
And there are methods that are usually only used at the outermost level (i.e., do not become an argument of another method call), as opposed to no/few methods that only appear as the innermost level. Typical examples of the former are DSL methods (methods that are conventionally used without parentheses like puts, p can be considered parts of the DSL provided by Ruby itself).
Once you decide to base the rule on what the method is, it follows naturally that you would be omitting the outermost parentheses that appear with particular methods.
This is a primarily opinion-based question, but Ruby Style Guide is a good (best?) reference when style-related questions appear.
Assuming it should be consistent with rest of the assert in tests, and looking at way asserts are used in Rails tests (i.e. with no parenthesis), it will be apt to use
assert method(param1, param2, etc)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
7.2 Blocks in Ruby says..
"block is a piece of code that can't be stored in a variable and isn't an object. It is, as a consequence, significantly faster than a lambda, but not as versatile and also one of the rare instances where Ruby's 'everything is an object' rule is broken"
Going by Best explanation of Ruby blocks?, that doesn't seem right.
Are blocks (Proc) objects? And thus don't break the everything is object rule in Ruby?
No, blocks are not (Proc) objects (although it is easy to map from one to the other).
Obviously, "everything is object in Ruby" is wrong in the absolute sense. A character is not an object. Even if limit your attention to tokens, keywords are not objects; comments are not objects; parentheses are not objects. So it is not surprising that a block is not an object.
Every proposition has contexts in which it is to be interpreted. When people say "everything is object in Ruby", the context is "with respect to what some major languages regard as atomic/scalar, such as numerals, etc."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Ruby has support for the for i in a syntax, but no one really uses it. One of the design principles of Ruby is it's readability, and I find
for i in a
...
end
much more readable (and easier to type) than
a.each do |i|
...
end
Why is it not preferred? Do others not also find it more readable? Is it for consistency reasons, e.g., relation with other functions like each_with_index and variable scoping?
For me, it's uniform syntax. When I am going to do something with array a, I just start typing a.. What am I going to do? Filter? a.select; determine the size? a.size. Iterate? a.each etc.
Iterating an array is nothing special and requires no special language construct. Also eachwithout an immediate block results in an Enumerator, which can be chained with other methods.
Then again, Ruby does have a fine for i in a loop. So if you are more comfortable with a for loop: by all means, use a for loop.
Because for loop is less objective and more limited in use.
From the OOP point of view, possibility of iterating through elements of an object is a property/characteristic of that object. Using explicit "outer" way either with a global function or a keywords find redundant, inconsistent and less objective (encapsulation).
for is also more limited, it allows only iterate through object elements. Enumerator#each on the other hand allows you much more. You may play with enumerator object like chaining with other methods before values unpacking, passing named blocks, methods converted to procs etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
while browsing for a contains method, I came across the following Q&A
contains-method-for-a-slice
It is said time and again in this Q&A that the method is really trivial to implement. What I don't understand is, if it were so easy to implement, and seeing how DRY is a popular software principle && and most modern languages implement said method , what sort of design reasoning could be involved behind the exclusion of such a simple method?
The triviality of the implementation depends on the scope of the implementation. It is trivial to implement when you know how to compare each value. Application code usually knows how to compare the types used in that application. But it is not trivial to implement in the general case for arbitrary types, and that is the situation for the language and standard library.
Figuring out if a slice contains a certain object is an O(n) operation where n is the length of the slice. This would not change if the language provided a function to do this. If your code relies on frequently checking if a slice contains a certain value, you should reevaluate your choice of data structures; a map is usually better in these kind of cases. Why should the standard library include functions that encourage you to use the wrong data structure for the task you have?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is considered more appropriate style of writing conditional operators?
if(1){
puts("Hello")
}
or
if(1) puts("Hello")
Similar aspects of coding style are welcome too.
That's all depends on your preference, that's why we rarely see people code in the same style.. Moreover, it depends on which programming language you're using.. IMHO, the important thing in coding is code readability and comments, so when your BOSS asks other people to help or develop your code. He /she will spend the least amount of their time to understand your code..
If you ask specifically from your example above, I would prefer the first one.. Because in my OPINION, imagining the WHOLE code, that one will give better readability. HOWEVER, some people may argue that it will spend some of your time typing those brackets over and over..
As per the PSR standards any structure must always enclose the code in parentheses.
The body of each structure MUST be enclosed by braces. This standardizes how the structures look, and reduces the likelihood of introducing errors as new lines get added to the body.
from the official website
Please have a look under control structures section http://www.php-fig.org/psr/psr-2/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I know that there are a couple ways to loop in various languages - a "for" loop, a "while" loop, a "do-while" loop, and just "loop" in Ruby for example. And I know there are various functions in every language that are pre-written in that language - for example the .each function in Ruby (which I think is based on a "for" loop and written entirely in Ruby and is replicable just using the language).
But what is the logic behind loops? Are they programmed from control flow statements in Assembly or even binary? And in fact, now that i think about it, what is the origin of all programming structures in general (such as variable name/value associations, arrays, hashes, etc - sorry if my terminology is wrong). Can anyone recommend sources to read more on this?
Loops in general are jumps in the program flow. When you compile your code i.e. in C, it gets "converted" to assembly, where you can see that loop structure:
So you start at a certain adress and do some stuff (i.e. ADD) which basically is everything inside your loop. At the very end then is a jump instruction back to the adress where you started. Breaking is is then i.e. made through a conditional jump inside your loop and thus you don't get to the jump instruction again and therefore do not loop again.