Nelis75733126/Sandbox – User
Jump to navigation
Jump to search
m (punctuation.) |
|||
| Line 1: | Line 1: | ||
== About writing SQF code without negation == | == About writing SQF code without negation == | ||
{{ Feature | Informative | | {{Feature|Informative|'''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 wherever that is practical.<br> | ||
This page is about a '''subjective''' topic. This article was written by someone who is a proponent of avoiding negation | The author of this article wants to make it 100% clear that code written '''with negation''' is still '''functional''' and capable of getting results.<br> | ||
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, code can be written in multiple styles. One of which is using negation. Another can be to write with limited negation. | ||
Like every other language, | It all comes down to subjective preferences or how much you care about readability.}} | ||
=== What is "negation"? === | === What is "negation"? === | ||
Negation refers to formulating a sentence in a negative way. Here are some examples: | Negation refers to formulating a sentence in a negative way. Here are some examples: | ||
| Line 35: | Line 35: | ||
}; | }; | ||
</sqf> | </sqf> | ||
<sqf> | <sqf> | ||
// same result as example above, but without negation. | // same result as example above, but without negation. | ||
| Line 46: | Line 45: | ||
}; | }; | ||
</sqf> | </sqf> | ||
In the two examples above, avoiding negation makes the code a lot more simple and avoids many nested checks. | In the two examples above, avoiding negation makes the code a lot more simple and avoids many nested checks. | ||
=== | === Where avoiding negation becomes...... awkward === | ||
When trying to avoid negation in all types of situations, it can get awkward inside of a function that COULD have a parameter that needs to be handled IF it is something other than Null.<br> | |||
As you are probably aware, there is no such thing as a command which checks for the opposite of <sqf inline>isNull</sqf>. | |||
For example, in a function where passing a control is '''optional''': | |||
<sqf> | <sqf> | ||
[ controlNull, true ] call { | [ controlNull, true ] call { | ||
params [ | |||
if( | ["_this0", controlNull,[controlNull]], | ||
["_this1", false,[false]] | |||
]; | |||
// | if NOT(isNull _this0) then { systemChat "the control exists" }; | ||
// if it is null, just move on quietly. | |||
if( _this select 1 ) then { systemChat str( random 9000 ) }; | if( _this select 1 ) then { systemChat str( random 9000 ) }; | ||
}; | }; | ||
</sqf> | </sqf> | ||
In the example above, the goal is to just move on if an argument is missing or null. therefore, avoiding negation with <sqf inline>exitWith</sqf> is impossible.<br> | |||
If one were to write that same code without negation, '''it would become very complicated, harder to read, and SLOWER''' than simply using <sqf inline>NOT</sqf>. | |||
An example of that can be seen below: | |||
<sqf> | <sqf> | ||
[ player ] call { | [ player ] call { | ||
if( ( ( str( _this select 0 ) find "NULL" ) == -1 ) then {}; | if( ( ( str( _this select 0 ) find "NULL" ) == -1 ) then {}; // yes it works, but is a lot slower than just using NOT(isNull) | ||
}; | }; | ||
</sqf> | </sqf> | ||
| Line 78: | Line 73: | ||
Then, simply look for <sqf inline>"NULL"</sqf> in there, and if [[find]] returns -1, it sure is a valid object! | Then, simply look for <sqf inline>"NULL"</sqf> in there, and if [[find]] returns -1, it sure is a valid object! | ||
=== | === CONCLUSION === | ||
Yes, it is possible to avoid negation entirely. However, there is a cost. '''Depending on the situation, it can lead to a significant increase in code execution time.'''.<br> | |||
Therefore, it would be fair to say that striving to avoid negation can be beneficial to the readability of the code, but it becomes a paradox when avoiding it in any given situation. | |||
<br> | |||
< | |||
{{ Feature | Informative | The content of this page is purely meant to invoke a productive discussion or to inspire someone who might also want to use "positive code".<br> | {{ Feature | Informative | The content of this page is purely meant to invoke a productive discussion or to inspire someone who might also want to use "positive code".<br> | ||
'''This page means to only offer up another way of writing SQF code, without invoking any hierarchical '''this is better''' nonsense.}} | '''This page means to only offer up another way of writing SQF code, without invoking any hierarchical '''this is better''' nonsense.}} | ||
Revision as of 12:34, 1 May 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.
/*
with negation, basic checks on params.
a typical "only continue if all parameters meet the required conditions"
*/
[ controlNull, objNull, 0, true ] call {
if( !isNull( _this select 0 ) ) then {
if( !isNull( _this select 1 ) ) then {
if( !isNil{ _this select 2 } ) then {
if( !isNil{ _this select 3 } ) then {
systemChat "all checks passed";
};
};
};
};
};
// same result as example above, but without negation.
[ controlNull, objNull, 0, true ] call {
if( isNull( _this select 0 ) ) exitWith {};
if( isNull( _this select 1 ) ) exitWith {};
if( isNil{ _this select 2 } ) exitWith {};
if( isNil{ _this select 3 } ) exitWith {};
systemChat "all checks passed";
};
In the two examples above, avoiding negation makes the code a lot more simple and avoids many nested checks.
Where avoiding negation becomes...... awkward
When trying to avoid negation in all types of situations, it can get awkward inside of a function that COULD have a parameter that needs to be handled IF it is something other than Null.
As you are probably aware, there is no such thing as a command which checks for the opposite of isNull.
For example, in a function where passing a control is optional:
[ controlNull, true ] call {
params [
["_this0", controlNull,[controlNull]],
["_this1", false,[false]]
];
if NOT(isNull _this0) then { systemChat "the control exists" };
// if it is null, just move on quietly.
if( _this select 1 ) then { systemChat str( random 9000 ) };
};
In the example above, the goal is to just move on if an argument is missing or null. therefore, avoiding negation with exitWith is impossible.
If one were to write that same code without negation, it would become very complicated, harder to read, and SLOWER than simply using NOT.
An example of that can be seen below:
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!
CONCLUSION
Yes, it is possible to avoid negation entirely. However, there is a cost. Depending on the situation, it can lead to a significant increase in code execution time..
Therefore, it would be fair to say that striving to avoid negation can be beneficial to the readability of the code, but it becomes a paradox when avoiding it in any given situation.