This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Jarrod Roberson
I keep seeing articles that demand the reader "Stop doing" something that is good just because they saw some demo on youtube and that person was not doing that thing and it now gospel to never do it again.
Stop saying "Stop using Else" and other nonsense!
This is a very concrete example of advice that is at best misinformation and at worse malicious misdirection.
If you google "stop using else" you will get pages and pages of articles written mostly by people that only have passing experience in a single language, usually JavaScript, and have never written a program with total lines of code greater than 10K, espousing this nonsense as if it was a revelation of some new gospel.
Its not, it is an ancient screed from the Cult of the Lines of Code Gospel or the Followers of the Optional Braces disciples repeat these mantras and have no experience with what they are saying in the larger picture.
Explicit Is Better Than Implicit!
This is from PEP 20 - The Zen of Python but it applies to all higher level languages and is knowledge that was learned from working with previous languages that were dominated by the "Cult of the Lines of Code" acolytes, this cult still preaches such things as the First 80 Columns are the only holy columns fallacy in 2022 as well.
This statement should be self explanatory and non-controversial. Program code that is explicit is unambiguous in its intent on what its behavior is expected to be.
That is not to say that its behavior is correct, it is just that it is not a mystery what the desired output of any input is expected to be. Executable Code should be the definitive source of logic, and comments are not executable even if they are semantically code.
Else is explicit its absence is intentional obfuscation!
The same cult that is espousing this nonsense now is the same cult that exposed the nonsense of leaving off {} from if statements and for the exact same reasons.
The most popular ones are, "they are not needed", "they increase lines of code or keypresses", "they are more to read", etc. All of them are backed by logical fallacies as why they are correct.
Leaving off an else statement never adds any information, it removes information about what the code is intended to do. Anything that removes information in this case is harmful.
Some languages are harmed more than others!
Leaving off the else block in languages like Python are even more harmful than the languages most of these authors are using to justify their ideology. Go and JavaScript I am looking at you.
The lack of block characters, or leaving off block characters (which is worse), makes these types of logic bombs even harder to reason about when they explode and you can not see where the issue is just looking at the code. Especially, when they cause intermittent bugs because the bad logic only triggers occasionally based on some state machine that is not defined and impossible to reason about when the application is running much when you are looking at the source.
Garbage In/Garbage Out
This stop using ??? advice is primarily predicated on bad advice that the reader does not comprehend as bad advice because of lack of comprehension from lack of experience.
These same people will mindlessly espouse concepts like DRY and SOLID, avoid side-effects and completely ignore that this advice introduces implicit logic solely based on side effects.
The reasoning in this case is basically some form of "else is just fluff and adds nothing useful" and then follows with "you should code the if clause and return inside it and then do whatever the else is without the else statement and return there". There is a Luke Skywalker quote from a terrible movie that applies to this but I will not subject you to here.
This is terrible practice and it immediately introduces an impossible to detect bug into the logic of the code. Maybe not one that causes incorrect output immediately, but one that can the very first time someone adds any code outside that initial if block.
All logic is special case!
The misinformation is that the if statement is a special case in some way and that the else is the default/non-special case and does not need special treatment or demarcation.
The fact that you can transpose this specialness just by changing the initial if to if not tells you this is a flawed reasoning.
if somethingSpecial:
doSomethingSpecial()
doSomethingElseNotSpecial()
if not somethingSpecial:
doSomethingElseNoSpecial()
doSomethingSpecial()
No there is something even more fundamentally wrong with one of these pseudo-code logic above other than the missing else but that is another religious argument where the zealots are wrong as well.
Not Just One Billion Dollar Mistake!
null has been called a Billion Dollar Mistake by its creator. It is arguable that he was off by at least an order of magnitude initially, multiple orders by 2022 standards.
It was just one of many terrible ideas that language creators implement because most of them were not trained in formal logic or even trained in writing computer languages.
Necessity is the Mother
Many popular programming languages were created out of some need as a tool as a means to a very specific end, until C. C was created to be a general purpose language, and as such includes a kitchen sink of bad ideas that are only obvious in hind sight, sometimes even with 50 years of hindsight they are still obvious to some people.
One of the most subtle bugs in C is the one line if statement, that leaves off the {}. If someone comes along and just adds another line of code below the initial line in the if statement, what were their intentions?
Usually their intention was to add that line to the if statement, but that is not what happens. It is just executed regardless, which introduces can be an extremely subtle bug that can decimate data in an very quiet way that may not become apparent for hours, days, weeks or even months later.
Leaving off the else introduces the same class of bug, if not always the same level of subtly.
Languages like Go that are planned and designed for a reason just as a reaction to some problem leave a lot of these organic mistakes behind.
Unfortunately Go has just as many opinion based mistakes baked into them to replace the mistakes they avoided. Which personally I think is worse, because these mistakes are based on intention instead of accident. They become dogma immediately, no matter how bad they reveal themselves to be.
They become defining aspects of the language that drive away adoption because they are expected to be adopted by everyone; regardless of how bad an idea it actually ends up being, instead of cautionary tale features that are accepted as being avoided.
New ideas are not always new or correct!
One of the most offending languages right now to this is Go. There is a preponderance of effort into pushing the idea that else is not needed, and if it is your code is not structured enough or some other hand wavy non-sense that is your failing and not the failing that it is a terrible practice.
Another, idiom of Go is the normalization of negative Boolean checks in if statements.
if err != nil {
// do the expected logic here
}
This is the idiom in Go, and it is terrible for many reasons.
First off, the general and correct consensus is that the initial if statement should be not be testing for a negative because it forces more processing on the organic computer that is parsing and interpreting the intent of the logic.
Who in their right mind would let the following type of code construct into an application that was used for anything non-trivial?
if x != true && y != false && z == true {
}
Yet, I have seen thousands of lines of such checks in 20+ year old Java code that the original author insisted was *"best practices" 20+ years later. Lucky for me that IntelliJ idea was able to convert them all to something easier to reason about automatically. We still had to reason about the multiple checks and normalize that, but it did save time and make writing tests for this code possible.
The Go idiom is not exactly the same, but is in the same class of obfuscated logic for the sake of brevity, even if you consider it less harmful than the Java example. Less harmful is not harmless.
Religious Arguments Codified As Idioms are Dogma
Go codifies the "multiple return" religious argument dogma by making it an idiom. It does not solve the argument, it justifies it as "everyone says so", which is just a logical fallacy.
It does this, by making this the idiom in all the official Go source code.
This also has the side effect of justifying that else is never needed and thus it is idiomatic as well to always leave it out.
Leading many people to twist otherwise clear logic in obfuscated knots and write spaghetti code to be able to leave it out.
This Page Left Intentionally Blank
Documents that had important information that needed to be unambiguous in their facts and intention always have blank pages that say THIS PAGE LEFT INTENTIONALLY BLANK, on them in huge block letters. That way no one would wonder if that blank page was supposed to be blank and missing information? Was it a printing error? Is there missing information that could be a cause a serious error? No one would argue these semantic place holders were redundant or not important in the explicit context that they provide.
The else in the if/else symmetry serves this same semantic function. It says explicitly, THIS AND ONLY THIS is what is supposed to happen if the other thing is not true and leave no ambiguity.
It says, if you want something to happen if that special case is not true put it here. If you want something to happen regardless of that space put it outside here.
// something that might return an error
if err != nil {
return err, nil
}
// something ELSE or something unrelated to the previous if we have to look and parse to know that might return an error
if err != nil {
return err, nil
}
// something ELSE or something unrelated to the previous if we have to look and parse to know that might return an error
if err != nil {
return err, nil
}
// something ELSE or something unrelated to the previous if we have to look and parse to know that might return an error
if err != nil {
return err, nil
}
return nil, somethingNotNil
is what most would consider idiomatic
the following is not wrong but is preferable because of it is explicit and unambiguous to the expected behavior
if err != nil {
return err, nil
} else {
return nil, somethingNotNil
}
the needlessly laconic idiom version saves an entire 7 characters, but is introduces the possibility of endless subtle bugs as unattended side effects, incorrect logic and just bad output.
Thankfully, even this idiomatic structure is being challenge by the new/late comers to Go, but in an early enough stage and by enough seasoned developers that it can hopefully be corrected as harmful dogma from early zealots.
The fact that if err != nil is well considered to be just copy paste boilerplate with dozens of macros, libraries, frameworks, and code generator solutions to this should tell you it was never a good idea.
Ignore advice that makes the world worse!
It is very simple:
If the advice in any way makes your code less explicit, introduces any kind of possibly ambiguousness or obfuscation to the intent of the logic expressed as code, then ignore that advice.
This should tell you that all these stop using else articles just as bad for the industry as the same arguments espoused on Usenet in the 1980s promoting omitting optional braces in C for the same incorrect reasons.
This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Jarrod Roberson
Jarrod Roberson | Sciencx (2022-10-02T03:45:54+00:00) Stop writing “Stop doing ???” articles …. Retrieved from https://www.scien.cx/2022/10/02/stop-writing-stop-doing-articles/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.