What is the most readable way of writing a very simple function that is effectively executing one statement, if a condition is met?
What I find most readable is this:
function doSomething(myNumber){
if(myNumber !== null && myNumber > 5){
doTheThing();
}
}
However, my colleague insists that guard clauses make anything more readable, and would always write this function like this:
function doSomething(myNumber){
if(myNumber === null || myNumber <= 5)
return;
doTheThing();
}
I understand that guard clauses can be way more readable in bigger functions, especially if there is a need to check for multiple conditions, and/or if exceptions need to be thrown. But in a case like this, I always have to do a triple-take to understand in which case doTheThing() will be executed, which seems ridiculous for such a simple function.
This is not really a technical question, but rather a choice of style.
There are many ways you can write that function and the compiler will try to optimise it as best as possible. As for "readability" this is purely up to the programmer's choice. As long as you follow the language rules and standards, then any choice is fine. Of course if you work in a team it might be better to agree on a certain style, so that everyone can work on the code without getting confused.
Personally, if I really want to make it readable I would do this:
function doSomething(myNumber)
{
if(myNumber != null && myNumber > 5)
{
doTheThing();
}
}
On the other hand if I want less lines of code I would choose this:
function doSomething(myNumber) {
if(myNumber == null || myNumber <= 5) return;
doTheThing();
}
Also it is important to consider how the if statement should be. In this case you cover all possibilities, but just keep it in mind to avoid unexpected errors.
Related
I realize that it's not valid ruby but what would be the technical hurdles to implement the below functionality into the Ruby core language (of say v2.3)?
variable = 1 if condition else -1
I'd also like to allow the following for more generic use.
variable = { 1 } if condition else { -1 }
I'm very open to requiring an "end" at the end.
I get that a ternary can easily accomplish this but I'm looking for a more readable inline-if that allows an else.
I get that I can make a function which does this via any number of styles but I'd prefer to have it as readable as possible.
Thanks.
EDIT: I hate editing questions for obvious reasons.
In response to the question of how the generic option is more ruby-esque, see the below example (I needed newlines).
variable = {
operation_one
operation_two
...
SUCCESS_STATUS_CODE
} if loaded_dependencies else {
do_detailed_logging
FAILURE_STATUS_CODE
}
if variable then
it_worked
else
explain_why
end
Because your example, while it seems readable to you, has too many ambiguities in other cases.
Not to mention that ruby has a way to do this, and it's the ternary operator. To say that your example is more ruby-like, is almost like wondering why the wheelbase of the Ford Mustang wasn't longer, and that it would be more "Mustang-like" if it was.
But here are some issues with your proposal, starting from your example:
variable = { 1 } if condition else { -1 }
Here you've given your "if else" bit a lower precedence than the "=".
In other words:
variable = ({ 1 } if condition else { -1 })
That's a serious problem, because it breaks the currently allowed:
variable = 1 if condition
The precedence for that statement is:
(variable = 1) if condition
And that's important. No assignment happens if the condition is false.
This can be a really big deal, for example if the lvalue (left side) actually has side-effects. For example:
var[0] = 1 if condition
The lookup for "var[0]" is a method in whatever class object var is, and while [] doesn't usually have side-effects, it can - and now you are going to do those side effects even if the condition is false.
And I won't even get into:
variable = { 1 } if condition if condition2 else { -1 }
But if you don't like it, you can always write your own language and see what happens!
I have a rather specific question.
Say I am at the end of a function, and am determining whether to return true or false.
I would like to do this using an if/else statement, and have two options: (examples are in pseudocode)
1) Check if worked first:
if(resultVar != error){
return true;
}else{
return false;
}
2) Check if it failed first:
if(resultVar == error){
return false;
}else{
return true;
}
My question is simple: Which case is better (faster? cleaner?)?
I am really looking at the if/else itself, disregarding that the example is returning (but thanks for the answers)
The function is more likely to want to return true than false.
I realize that these two cases do the exact same thing, but are just 'reversed' in the order of which they do things. I would like to know if either one has any advantage over the other, whether one is ever so slightly faster, or follows a convention more closely, etc.
I also realize that this is extremely nitpicky, I just didn't know if there is any difference, and which would be best (if it matters).
Clarifications:
A comparison needs to be done to return a boolean. The fact that of what the examples are returning is less relevant than how the comparison happens.
This is by far the cleanest:
return resultvar != error;
The only difference in both examples may be the implementation of the operator. A != operator inverses the operation result. So it adds an overhead, but very small one. The == is a straight comparison.
But depending on what you plan to do on the If/else, if there is simply assigning a value to a variable, then the conditional ternary operator (?) is faster. For complex multi value decisions, a switch/case is more flexible, but slower.
This will be faster in your case:
return (resultVar == error) ? false : true;
This will depend entirely on the language and the compiler. There is no specific answer. In C for instance, both of these would be encoded rather like:
return (resultVar!=error);
by any decent compiler.
Put true first, because it potentially eleiminates a JUMP command in assembly. However, the difference is negligible, since it's an else, rather than an else if. There may /technically be a difference/, but you will see no performance difference in this case.
If I had literally 1000s of simple if statements or switch statements
ex:
if 'a':
return 1
if 'b':
return 2
if 'c':
return 3
...
...
Would the performance of creating trivial if statements be faster when compared to searching a list for something? I imagined that because every if statement must be tested until the desired output is found (worst case O(n)) it would have the same performance if I were to search through a list. This is just an assumption. I have no evidence to prove this. I am curious to know this.
You could potentially put these things in to delegates that are then in a map, the key of which is the input you've specified.
C# Example:
// declare a map. The input(key) is a char, and we have a function that will return an
// integer based on that char. The function may do something more complicated.
var map = new Dictionary<char, Func<char, int>>();
// Add some:
map['a'] = (c) => { return 1; };
map['b'] = (c) => { return 2; };
map['c'] = (c) => { return 3; };
// etc... ad infinitum.
Now that we have this map, we can quite cleanly return something based on the input
public int Test(char c)
{
Func<char, int> func;
if(map.TryGetValue(c, out func))
return func(c);
return 0;
}
In the above code, we can call Test and it will find the appropriate function to call (if present). This approach is better (imho) than a list as you'd have to potentially search the entire list to find the desired input.
This depends on the language and the compiler/interpreter you use. In many interpreted languages, the performance will be the same, in other languages, the switch statements gives the compiler crucial additional information that it can use to optimize the code.
In C, for instance, I expect a long switch statement like the one you present to use a lookup table under the hood, avoiding explicit comparison with all the different values. With that, your switch decision takes the same time, no matter how many cases you have. A compiler might also hardcode a binary search for the matching case. These optimizations are typically not performed when evaluating a long else if() ladder.
In any case, I repeat, it depends on the interpreter/compiler: If your compiler optimized else if() ladders, but no switch statements, what it could do with a switch statement is quite irrelevant. However, for mainline languages, you should be able to expect all constructs to be optimized.
Apart from that, I advise to use a switch statement wherever applicable, it carries a lot more semantic information to the reader than an equivalent else if() ladder.
I think this is fairly language-independent, but if I'm wrong, then go for C# (or C or C++).
With "simple" magic values I mean things like this:
if (Value > 0)
or
while (Value < 0)
or
while (MyQueue > 0)
While writing this (pseudo-code above) it kinda struck me that it really only applies to something being compared to 0.
Anyway, what's the best way to handle these sort of magic values (considering readability, amount of keystrokes/code to create and name)?
It feels like extreme overkill having an entire (static) class (or enum, in C#) dedicated to this.
Certain numbers are only considered "magic numbers" by their context. Some usages embody a simple concept that has nothing to do with the specific value of the number. For example, if you want to check if a list is not empty you might write one of the following statements:
if (list.Count != 0)
if (list.Count > 0)
if (list.Count >= 1)
Neither 0 nor 1 has any meaning beyond 'nothing' and 'something', and so the above three statements should be read as "not nothing", "more than nothing" and "at least something", and therefore I wouldn’t call their usages "magic numbers". There may be other ways to perform such a check without using any numbers at all. For example, in C# you could use the Any LINQ operator:
if (list.Any())
I find this to be more descriptive and enable story-like readability of code. Other languages may have other facilities to express concepts such as 'nothing', 'something', 'empty set', 'non-empty set', etc.
As Allon Guralnek stated I also would use the Any() extension methods to check if a certain collection contains items. You can also write additional extension methods like
public static class MyExtensions {
public static bool IsNegative(this int number) {
return number < 0;
}
public static bool IsPositive(this int number) {
return number > 0;
}
}
And then write your loop or conditions as
if (Value.IsPositive())
while (Value.IsNegative())
while (MyQueue.IsPositive())
assuming Value and MyQueue are of type int.
I have a for loop of the form:
for (int i = from; i < to; i++) {
// do some code (I don't know exactly what, it is subject to change)
}
And I want to convert it to a while loop (mostly because I want to play with the value of i inside the loop to go backwards and forwards and my co-worker thinks that doing this in a for loop is prone to problems. I tend to agree with him). So I wrote something like this:
int i = from;
while (i < to) {
try {
// do some code (I don't know exactly what, it is subject to change)
} finally {
i++;
}
}
Which prompted some some loud comments. My reasoning is that you don't know what the code inside the loop does - it may (and does) have multiple continue commands.
As a response he wrote this:
int i = from - 1;
while (++i < to) {
// do some code (I don't know exactly what, it is subject to change)
}
Granted its less lines, but I still think my code is more elegant - what do you think?
Playing with the value of your index while in a looping structure is prone to problems, no matter what the looping structure is.
It's not going to matter if it's a for loop or a while loop, the point is will the indexer eventually lead you to make a decision of loop termination?
If you're confident that you're indexer will eventually cause your exit condition to be achieved, then that is all you should be concerned with, not whether to use a for or a while.
And I want to convert it to a while loop (mostly because I want to play with the value of i inside the loop to go backwards and forwards and my co-worker thinks that doing this in a for loop is prone to problems. I tend to agree with him).
This is perfectly acceptable in most languages. There is no reason to avoid a for loop.
It seems to me that it may be easier and more readable to convert it to:
while (condition == true) {
// do stuff
// set the condition flag appropriately
}
and thus separate the termination of the loop from the variable incrementation.
If I see a loop with a limit check (e.g. i < limit) I would tend to assume that there's a variable that is being modified in a (reasonably) consistent fashion. There's no reason why you can't do what you want, but I would lean towards the more readable and more expected behaviour.
Why bother with silly loops when you can do the same (and much more!) with the uber-powerful goto?
i = fro;
my_loop:
//all your stuff here
i++;
if (i < to) goto my_loop;
If you are one of those faint hearted programmers that diminish the goto, then you can try with this:
i = fro;
while(1) {
//your stuff here
if (++i < to) break;
}
The easiest way to do this would be to not convert into a while loop, such as below.
for (int i = from; i < to; ) {
// do some code (I don't know exactly what, it is subject to change)
i += rand()*10;
}
To answer the question about which code I would select; I choose your longer code. Its MUCH easier to read the first(longer) loop. And yes I can read the second but even if you have lots of experience you have to look twice to know what that loop does. Plus the compiler will optimize the code well enough.