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 1 year ago.
Improve this question
Seems like in most cases it would make more sense to use the pre yet somehow post is far more common.
while (counter < 10)
counter++;
After reading everything I can find on the history of ++ and --, it seems that there is no technical reason for this convention, if it is even a convention (more on that later). Hence, I assume it must be an issue of a personal preference evolved. I'd posit that it has to do with readability. counter++ could be seen as more intuitive than ++counter because it is an assignment operator. Essentially, it's shorthand for counter = counter + 1. Here you have the increment on the right being assigned to the left-hand expression. counter++ naturally better fulfills this logic.
However, it is not necessarily a convention. Some would argue that the prefix operator is always better (admittedly for mostly historical reasons). Personally, I prefer the prefix because it makes more sense to me in the context of other unary operators like &, *, etc. as well as the possible speed optimization.
Maybe it is there rebelious nature. "Who cares about speed?". ++i and i++ are just as easy to read. I didnt even concieve that persons would have a warm time understanding ++i. But where I am standing, there is no difficulty reading any of them. So I choose the one that has less overhead. It is not a big boost, but it is also not harder to type.
Related
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)
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
Many contemporary languages allow two kinds of comments: one in which delimiters are used on both ends (multiple-line comments), and one in which a delimiter marks only the beginning of the comments (one-line comments). Discuss the advantages and disadvantages of each with respect to criteria (readability, writability, reliability, cost).
There's no right answer here, they differ in a personal or style-wise way of coding.
With both you have a easy to write/read comment. The comment may be as long as you want, but generally short and precise comments are better, otherwise you would only be rewriting code as comment.
//assings 10 to x will make everything happier // the code won't change (further reading)
x = 10
if (x == 10)
happy++
How did this comment helped future users?
With multiple lines, though, you can write a little text, but reading it would be a little extra work if you still had to read (and understand) the code.
It won't change how programmers will read them, but they sure help when you have more than one line of comment (like reference URL's) and don't want to start every line with a comment markup.
I, personally, like multiline code for a simple reason: it agroups logical parts together
//*assings 10 to x will make everything happier //the code is on
x = 10
if (x == 10)
happy++
//*/
Now I can easily turn the code betwen those comments on and off that part of the code (for testing, for instance) only by changing the first "/". It would be a advantage of multiline.
/*assings 10 to x will make everything happier // the code is off
x = 10
if (x == 10)
happy++
//*/
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've read posts where people say certain compilers will implement recursion as loops but the hardware implements loops as recursion and vice versa. If I have a recursive function and an iterative function in my program, can someone please explain how the compiler and hardware are going to interpret each one? Please also address any performance benefits of one over the other if the choice of implementation does not clearly favor one method like using recursion for mergesort.
Ok, here is a brief answer:
1)A compiler can optimize tail recursive calls. But it is usually not a loop, but rather a stack frame reuse. However, I have never heard of any compiler that converts a loop into recursion(and I do not see any point of doing so: it would use additional stack space, likely to work slower and can lead to the change of semantics(stackoverflow instead of an infinite loop)).
2)I would say that it is not correct to speak about hardware implementing loops, because hardware itself does not implement loops. It has instructions(like conditional jumps, arithmetical operations and so on) which are used to implement loops.
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/