Nelis75733126/Sandbox – User

From Bohemia Interactive Community
< User:Nelis75733126
Revision as of 23:24, 22 April 2024 by Nelis75733126 (talk | contribs) (Created page with "== About writing SQF code without negation == {{ Feature | Informative | '''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> 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 usi...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

About writing SQF code without negation

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.
The author of this article wants to make it 100% clear that code written with negation is functional and capable of getting results.

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"?

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.

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:

[ controlNull, true ] call { // the point is to just continue controlNull is passed, but do something when an actual control is passed. if( ctrlIDC( _this select 0 ) > -1 ) then { // ctrlIDC will return -1 if it checks a controlNull systemChat "seems to be a control that exists"; }; // do some other stuff below here if( _this select 1 ) then { systemChat str( random 9000 ) }; };

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:

[ player ] call { if( ( ( str( _this select 0 ) find "NULL" ) == -1 ) then {}; };

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:

[ objNull, true ] call { if( ( _this select 0 ) isEqualType objNull ) then { // will return true even if the object is null. if( isNull( _this select 0 ) ) exitWith {}; // yes there is exitWith again :) systemChat "that object exists."; }; if( _this select 1 ) then { systemChat "hello world" }; };

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.

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". This page means to only offer up another way of writing SQF code, without invoking any hierarchical this is better nonsense.