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.










share|improve this question









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















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.










share|improve this question









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













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.










share|improve this question









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






share|improve this question









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.











share|improve this question









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.









share|improve this question




share|improve this question








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


















  • 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










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.






share|improve this answer





















  • 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




















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.






share|improve this answer





















  • 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

















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.






share|improve this answer





















  • 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















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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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




















  • 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





Popular posts from this blog

List directoties down one level, excluding some named directories and files

list processes belonging to a network namespace

list systemd RuntimeDirectory mounts