Using 'else' strategically when not needed [on hold]
up vote
-3
down vote
favorite
Is it a bad idea to include else's when not needed to make the logic more clear ? I've done this more with PHP with longer drawn out if/else's but if you look at the following code (bash) you can get the gist of what I'm saying. Again it's not the most useful example since we are really comparing the same thing 'user' :
How most people do it:
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
done
Alternative version :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
else
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
fi
done
Thoughts? I personally like the 'alternative', usually keeps me out of trouble more often and I find it easier to read.
UPDATE: going to provide a more "complex" example to show the needlessness of strict use of elif :
Using elif religiously :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [ "$user" == "root" ] && ! isAdmin ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && ! isAdmin ;then
echo "command2"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && isAdmin ;then
echo "command3"
fi
done
Breaking it down a bit :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if isAdmin ;then
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command3"
fi
else
if [ "$user" == "root" ] ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command2"
fi
fi
done
So what right ? Well my point is that one is more clear to it's intentions IMO and hence easier to debug.
bash
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Toby Speight, 200_success, AJNeufeld, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ Nov 19 at 19:12
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Toby Speight, 200_success, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ
If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 1 more comment
up vote
-3
down vote
favorite
Is it a bad idea to include else's when not needed to make the logic more clear ? I've done this more with PHP with longer drawn out if/else's but if you look at the following code (bash) you can get the gist of what I'm saying. Again it's not the most useful example since we are really comparing the same thing 'user' :
How most people do it:
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
done
Alternative version :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
else
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
fi
done
Thoughts? I personally like the 'alternative', usually keeps me out of trouble more often and I find it easier to read.
UPDATE: going to provide a more "complex" example to show the needlessness of strict use of elif :
Using elif religiously :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [ "$user" == "root" ] && ! isAdmin ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && ! isAdmin ;then
echo "command2"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && isAdmin ;then
echo "command3"
fi
done
Breaking it down a bit :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if isAdmin ;then
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command3"
fi
else
if [ "$user" == "root" ] ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command2"
fi
fi
done
So what right ? Well my point is that one is more clear to it's intentions IMO and hence easier to debug.
bash
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Toby Speight, 200_success, AJNeufeld, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ Nov 19 at 19:12
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Toby Speight, 200_success, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ
If this question can be reworded to fit the rules in the help center, please edit the question.
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
1
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37
|
show 1 more comment
up vote
-3
down vote
favorite
up vote
-3
down vote
favorite
Is it a bad idea to include else's when not needed to make the logic more clear ? I've done this more with PHP with longer drawn out if/else's but if you look at the following code (bash) you can get the gist of what I'm saying. Again it's not the most useful example since we are really comparing the same thing 'user' :
How most people do it:
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
done
Alternative version :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
else
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
fi
done
Thoughts? I personally like the 'alternative', usually keeps me out of trouble more often and I find it easier to read.
UPDATE: going to provide a more "complex" example to show the needlessness of strict use of elif :
Using elif religiously :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [ "$user" == "root" ] && ! isAdmin ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && ! isAdmin ;then
echo "command2"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && isAdmin ;then
echo "command3"
fi
done
Breaking it down a bit :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if isAdmin ;then
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command3"
fi
else
if [ "$user" == "root" ] ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command2"
fi
fi
done
So what right ? Well my point is that one is more clear to it's intentions IMO and hence easier to debug.
bash
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Is it a bad idea to include else's when not needed to make the logic more clear ? I've done this more with PHP with longer drawn out if/else's but if you look at the following code (bash) you can get the gist of what I'm saying. Again it's not the most useful example since we are really comparing the same thing 'user' :
How most people do it:
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
done
Alternative version :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [[ "${user,,}" == "root" ]] ; then
echo "usermod -L $user"
else
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "usermod -s /usr/sbin/nologin $user"
fi
fi
done
Thoughts? I personally like the 'alternative', usually keeps me out of trouble more often and I find it easier to read.
UPDATE: going to provide a more "complex" example to show the needlessness of strict use of elif :
Using elif religiously :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if [ "$user" == "root" ] && ! isAdmin ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && ! isAdmin ;then
echo "command2"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] && isAdmin ;then
echo "command3"
fi
done
Breaking it down a bit :
for user in $(awk -F: '($3 < 1000) {print $1 }' /etc/passwd); do
if isAdmin ;then
if [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command3"
fi
else
if [ "$user" == "root" ] ; then
echo "command1"
elif [ $user != "sync" ] && [ $user != "shutdown" ] && [ $user != "halt" ] ;then
echo "command2"
fi
fi
done
So what right ? Well my point is that one is more clear to it's intentions IMO and hence easier to debug.
bash
bash
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited Nov 19 at 16:48
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 19 at 16:16
Mike Q
974
974
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Mike Q is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Toby Speight, 200_success, AJNeufeld, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ Nov 19 at 19:12
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Toby Speight, 200_success, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ
If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as off-topic by Toby Speight, 200_success, AJNeufeld, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ Nov 19 at 19:12
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Toby Speight, 200_success, πάντα ῥεῖ, Sᴀᴍ Onᴇᴌᴀ
If this question can be reworded to fit the rules in the help center, please edit the question.
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
1
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37
|
show 1 more comment
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
1
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
1
1
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
First of all, the pattern if (a==b) ... elif (a==c) is why switch statements exist. In bash, read about them here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_03.html
More generally - yes, using an else where an elif will suffice is a bad idea. It unnecessarily lengthens the code without any benefit to legibility. If you're concerned about the legibility of a very long segment of code, you have another problem: you need to subdivide the code into functions so that the blocks within the if statements are more legible.
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
First of all, the pattern if (a==b) ... elif (a==c) is why switch statements exist. In bash, read about them here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_03.html
More generally - yes, using an else where an elif will suffice is a bad idea. It unnecessarily lengthens the code without any benefit to legibility. If you're concerned about the legibility of a very long segment of code, you have another problem: you need to subdivide the code into functions so that the blocks within the if statements are more legible.
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
add a comment |
up vote
0
down vote
accepted
First of all, the pattern if (a==b) ... elif (a==c) is why switch statements exist. In bash, read about them here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_03.html
More generally - yes, using an else where an elif will suffice is a bad idea. It unnecessarily lengthens the code without any benefit to legibility. If you're concerned about the legibility of a very long segment of code, you have another problem: you need to subdivide the code into functions so that the blocks within the if statements are more legible.
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
First of all, the pattern if (a==b) ... elif (a==c) is why switch statements exist. In bash, read about them here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_03.html
More generally - yes, using an else where an elif will suffice is a bad idea. It unnecessarily lengthens the code without any benefit to legibility. If you're concerned about the legibility of a very long segment of code, you have another problem: you need to subdivide the code into functions so that the blocks within the if statements are more legible.
First of all, the pattern if (a==b) ... elif (a==c) is why switch statements exist. In bash, read about them here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_03.html
More generally - yes, using an else where an elif will suffice is a bad idea. It unnecessarily lengthens the code without any benefit to legibility. If you're concerned about the legibility of a very long segment of code, you have another problem: you need to subdivide the code into functions so that the blocks within the if statements are more legible.
answered Nov 19 at 16:27
Reinderien
1,332516
1,332516
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
add a comment |
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
I get what you are saying (good point about the functions), I've written a lot of bash code, so I just picked it here for that reason but when things get more complex, you may need more complex if/else's which usually doesn't happen in bash too much. I should have dug up a PHP example. So what I am getting for your comment is to basically just stay away unless super necessary.
– Mike Q
Nov 19 at 16:33
add a comment |
Yes, it's a bad idea :) The alternative is lengthier, has more indentation, and doesn't really improve legibility.
– Reinderien
Nov 19 at 16:24
@Reinderien I wouldn't write it off so fast. The focus is on the logic, this might not be the best example but it could detangle a lot of the code.
– Mike Q
Nov 19 at 16:28
1
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
– Toby Speight
Nov 19 at 17:19
I've voted to close this question as off-topic, because you are asking about a practice in general, with some snippets of code that serve merely as examples. As per the help center rules and the How to Ask guidelines, your code should accomplish a concrete task, and the title of the question should state what that task is.
– 200_success
Nov 19 at 17:35
Where does one ask the questions that I am asking then ?
– Mike Q
Nov 19 at 17:37