WelcomeWEFreedomWindsorEssexCounty-ActionCommunicationsRalliesResourcesSocialEventsWednesdayNightMeetings-ActivismAgoraAgorismCanadaCommonLawCommunityDataCentersDataCentresDoocracyFarmersMarketIntroductionsNaturalLawNewslettersOntarioOrganizingOutreachProjexProjexWikiRalliesResistanceAnalysisSoireesSoiréesWikiSpooksWindsorElectionsTop Subs
1
Coding - - (+0|-0)
Instances?(self)
8 commentsbyHigh_Quality_Dick_Pics
public static HighlightManager Instance { get; private set; }
public GameObject buildingHighlightObject;  // Prefab or object to use for highlighting

void Awake()
{
    if (Instance != null && Instance != this)
        Destroy(gameObject);
    else
        Instance = this;
}
--- what is the downside of the above flow? Why use EDA (event driven arch) if i can just instance things? I dunno, maybe a dumb question, but asking anyways. Is it racing conditions? Its racial isn't it.

Comment preview

[-]x0x70(0|0)
There's something about the logic of your code that I don't follow. To reach else we need Instance to == this, because if it is != this it will end up in the top block (unless it is null). So then really the Instance=this code is really only contingent on null otherwise it is redundant code.
if(Instance==null) Instance = this;
if(Instance!=this) Destory(gameObject);

That would be my style.
parentlinkreply
[-]High_Quality_Dick_Pics0(0|0)
Yeah, that looks way better and is more intuitive at a glance. I like.
parentlinkreply
[-]x0x70(0|0)
I've become a never-nester for the most part with code. I never nest if statements (at least rarely), and I almost never use else statements. I consider them both anti-patterns.
Instead I like to adapt patterns from functional language programming into iterative programming languages. Functional programming is better programming, iterative languages are better languages. The only thing wrong with functional programmers is they use absolutely awful pure functional languages.
So if you were doing functional programming you are first looking for edge cases and putting them at the top of the function.
So I basically do things in an order where I multiply (exceptionality of the conditional) (length of the conditional in code) (length of the related block in code).
The more exceptional and concise things are the more they end up a the top of the code, with the goal of returning if possible. This means that the code below only has to consider more narrowed cases turning the larger more complicated code even more simple.
This is also technically better for performance because the cpu is assuming conditionals are likely to be false and so branch prediction loads code past your conditional. 
if(assurances I can run main code) {
 //main code
}
else {
 //exceptional code
} // <- This is a bad pattern.
The CPU is loading the exceptional code like it is the main block.
parentlinkreply
[-]x0x70(0|0)
Best pattern is:
if(exotic state) {
 //Code
 return;
}
//Main logic.
parentlinkreply
[-]High_Quality_Dick_Pics0(0|0)
I have heard of branchless coding patterns before, where you remove the else entirely due to the cpu just kind of guessing what to compile and if it hits the wrong branch it says, "Oh fuck..." and then compiles the rest - i am totally butchering this as an explanation of my limited understanding cuz i just woke up! But i have never considered what that actually entailed. Thank you for the write up and the advice. Could you explain what you mean by "So I basically do things in an order where I multiply (exceptionality of the conditional) (length of the conditional in code) (length of the related block in code)." <- i am sleepy and dont get. Could you provide a function as an example? Iz good advice, ty.
parentlinkreply
[-]x0x70(0|0)
Basically the more exceptional conditions should go up top. The lest likely it is true the higher it should be. But also if the code that results is very simple that encourages it to be a little higher in the block all else being equal. And then if the conditional logic of the if statement is very simple it encourages it to be higher.
The last one often means that there are fewer states that could exist below the first if statement so the subsequent if statements end up more simple.
So instead of:
if(complicated)
if(simple)
You are more likely to end up with:
if(simple)  
if(moderate complexity)

Also this is better: 
if(occures 1/1000 times) {
 //Push things to a more normalized state or return the result of a more specialized function
}
//Remaining code
Is better than: if(Conditional that is true 999/1000 times) { //Main block of code for 30 lines } else { //Handle exception } ```
For some reason they teach the beginner level object oriented programmers to do it the second way. It's very java and ugly. Where as assembly programmers, C programmers, and functional programmers all handle exceptions first and main sequence of logic second. Do things the way functional programmers do. They are very good programmers because they have to make up for using the shittiest languages.
parentlinkreply