Nelis75733126/Sandbox – User
m (line breaks.) |
m (punctuation.) |
||
| Line 3: | Line 3: | ||
'''Important note from the author''' | '''Important note from the author''' | ||
This page is about a '''subjective''' topic. This article was written by someone who is a proponent of avoiding negation entirely.<br> | This page is about a '''subjective''' topic. This article was written by someone who is a proponent of avoiding negation entirely.<br> | ||
The author of this article wants to make it 100% clear that code written '''with negation is functional and capable of getting results | The author of this article wants to make it 100% clear that code written '''with negation''' is '''functional''' and capable of getting results.<br> | ||
Like every other language, they can be written in multiple styles. One of which is using negation. Another can be to write without negation. It all comes down to subjective preferences.}} | Like every other language, they can be written in multiple styles. One of which is using negation. Another can be to write without negation. It all comes down to subjective preferences.}} | ||
=== What is "negation"? === | === What is "negation"? === | ||
Revision as of 23:34, 22 April 2024
About writing SQF code without negation
What is "negation"?
Negation refers to formulating a sentence in a negative way. Here are some examples:
- "do NOT do that!"
- "do NOT change that thing!"
- "he is NOT happy!"
Simply put: any sentence with the word "NOT" in it is using negation.
Why care about negation?
Research has shown ( look it up if you wish ) that the human brain has more difficulty processing sentences with negation in it. Which could lead to the need for reading a sentence multiple times.
The same goes for code in any language.
exitWith is your friend :)
To show you why, here is an example of how something could be written with negation, followed by code without negation that does exactly the same thing.
In the two examples above, avoiding negation makes the code a lot more simple and avoids many nested checks.
The question of optional parameters
It can get tricky if a function COULD have a parameter that needs to be handled. For example, in a function where passing a control is optional:
If someone were to write that same function with negation, one would use NOT( isNull( _this select 0 ) ).
And, using the exitWith method in the example above will be undesirable because all the code after the check needs to be executed no matter what.
The conclusion is that when one tries to avoid negation, it is very likely that one needs to use less-than-obvious commands.
That might be ok for someone with enough experience, but it could get confusing for a beginner. Everyone will have to decide that for themselves.
the opposite of isNull?
There might come a time when you have to check if a parameter is the opposite of isNull, and do something if it is.
With negation, one would simply use if( not isNull objNull ) then {}; but when trying to avoid negation, it can get a bit......... creative:
What that does is it wraps the parameter into a string, which for objNull would become "<NULL-object>".
Then, simply look for "NULL" in there, and if find returns -1, it sure is a valid object!
Yes, it can get a bit "hacky"
Avoiding negation at all cost does come with potential "downsides" like slower code execution. The previous example is about half as fast as the !isNull approach.
In the end, it all comes down to what you prefer and how much speed you are willing to sacrifice for avoiding negation.
However, there can be instances where avoiding negation is actually faster then negation.
An example of how you can approach !isNull differently is like this:
The example above is slightly slower than negation. Again: if fast code execution is the most important thing to you, then by all means: use negation.