Wise words for programming

[Bribe]

Making sure your JASS code compiles properly is like Spell Check.

Thoroughly testing your code is like proofreading what you did to make sure your work actually make sense.

It takes both to make a quality system - please make sure to test your work and don't just rely on compiling it.

 

[WaterKnight]

GUI is like auto correct.

 

[Dr Super Good]

It takes both to make a quality system - please make sure to test your work and don't just rely on compiling it.

I think it is much more important to actually make something that is functionally efficient instead. I see a lot of people using structs and other nonsense when their problem could be solved with far less hassle using a few functions of standard JASS. Just because you can use structs does not mean you have to.

And then for all the OOPness they claim they are using they forget proper cleanup destructors and initializers. WE DO NOT NEED A SPELL TO RUN SCRIPT ON EVERY ABILITY CAST WHEN NO HERO HAS IT. And they go off arguing that variable name reduction is an optimization...

 

[Malhorne]

And then for all the OOPness they claim they are using they forget proper cleanup destructors and initializers. WE DO NOT NEED A SPELL TO RUN SCRIPT ON EVERY ABILITY CAST WHEN NO HERO HAS IT. And they go off arguing that variable name reduction is an optimization...

What do you mean ?

 

[BPower]

Strictly wc3 related I feel confident with adding tons debug lines in the first place and let the code yell at me what's going on. Later those get replaced with debug lines to ensure proper usage.

@Malhorne: RegisterSpellEffectEvent for instance makes sure, that only the corresponding script to an ability fires.
Imagine you have 100 custom spells in your map all of those will go off on spell effect event and only one passes the first condition vs only the correct script goes off at all.

 

[Malhorne]

Even with SpellEffectEvent you'll have to check even if it a bit more faster I don't get the point.

 

[WaterKnight]

Guess SpellEffectEvent is some custom library. You can directly assign the pieces of code that shall run when a specific ability is cast to that ability and then invoke that function dynamically. Thus you do not need if selections and do not need to filter out unwanted cast events on the ability's end.

Otherwise, if you had 100 abilities each with a trigger to run, all 100 triggers would get fired.

 

[Dr Super Good]

What do you mean ?

There is no need to generate ability events that fire on all abilities cast when the ability will never be cast the entire session as no one chooses a hero that can cast it. Equally well if heroes are removed that can cast the ability (like a leaver in an RPG) then there is no need for those triggers to persist for the rest of the session when the ability will no longer be cast.

As such all spells should have setup and breakdown support. Breakdown need not be fully leak-less or complete as long as it shuts down all persistent trigger overhead from the ability. In fact, setup might be as simple as enabling (turning on) the appropriate triggers if you want to be cheap since triggers that are off will not run code.

Why do they need this? Currently with the "Any unit begins an ability" style triggered abilities if you have 32 of them that is 32 trigger threads created per cast of any ability that evaluate 32 conditional tests in total. One can accept this overhead if at least 1 unit in the session can cast the ability but why must an ability that will never be cast in an entire session have such an overhead? Imagine not 32 triggered abilities, but 70, the overhead is now even larger yet only 6 of them might be cast able in a session.

This is the driving force behind some kind of setup and breakdown system for trigger enhanced abilities. If you make the setup unit specific you could even remove the overhead from all cast abilities for more efficiency. Equally well a complex ability mapping system could be used to interface with the generic events mapping them more efficiently than parallel events.

 

[Malhorne]

Okay I see what do you mean.
Yes event should be add upon hero choice and trigger removed when not needed anymore.

 

[Bribe]

Or, as others have mentioned, simply using SpellEffectEvent or some similar system so that you don't have to worry about manually enabling/disabling triggers.

 

[Magtheridon96]

Here are some wise words: A good API is not an API that makes the user think less, on the contrary, it's an API that makes the user think more.

Thinking less is why people make terrible design decisions and lose sight of the big picture when they're programming.

 

[Adiktuz]

yeah... as you go more into making things easier for users, the harder it becomes to make the code really efficient...

 

[Magtheridon96]

It's not about efficiency, it's about beautiful design :v

 

[Adiktuz]

oh well, but normally bad designs don't work as efficiently... at least from my experience...

 

[muzzel]

WHO THE FUCK CARES ABOUT EFFICIENCY.

Meg, i love you!

 

[SA Dashie]

Keep is simple. Keep is efficient. Keep it consistent. Keep is readable.

In general just keep it structured and designed well so all the code that
you have done can keep in collaboration for yourself and anyone else easily.

 

[GhostWolf]

Write code instead of silly "wise words" for other people.

 

[muzzel]

Those are truely wise words, GhostWolf.