1st year computer science student here. I'd like to know early on how to be a YandereDev so, what is a good alternative to all these nested ifs?
Fuck how to NOT be a Yanderedev.
A good alternative is a CASE statement. In case you need to know and haven't figured it out by yourself, one of the reason nested ifs are horribly inefficient is because all comparisons will be performed. A CASE statement works like multiple ifs, but instead of checking a million times for different values, it checks only once
>>865641>CASE statementI believe this is also called Switch case? If I'm reading this right, if you only need to compare one variable you should always use CASE statement instead of a bunch of ifs?
>>865620Build strong foundations and learn to architect your code before you even start. The abuse of the nested if statements Alex does is the least of his problems considering his compiler likely optimizes most of these patterns for him. He's built up so much technical debt from his choices that it would probably be faster for him to start over than to completely fix them all.
>>865644>>865641Erm, you can't switch on a string, because every complaint about nested if statements still applies just now the compiler is doing it.
I don't know wtf a YandereDev is, but you need to use a hash.
>>865709No, use a dictionary and let the underlying library do the work for you. There's no reason you can't write MyHashTableDictionary, but also no reason you should.
>>865620An option would be to replace all the strings with constants, and all the logic with a state machine, and all the if statements with a state machine interpreter.https://gamedevelopertips.com/finite-state-machine-game-developers/
>>865620You fell for the /v/ meme.Practically, there is nothing wrong with those nested ifs.The code is readable, you can easily edit it, and it isn't inefficient at all.Not saying it is perfect, but it's a perfectly valid way of programming.
>>865746No, it's really bad:>The code is readableTo a point; it's really quite flabby>you can easily edit itNo. For example, if I add another condition at the start, and accidentally use a "=", then Boris on the other team is left wondering why the condition he added two pages down is now broken>, and it isn't inefficient at all.It's O(n) where n is the total length of the strings being compared against. A hashtable is O(n^0.5), and a state table is O(1).
>>865620Pseudocode example of how to use a state machine>1st year computer science student herewhich you should be learning about RIGHT NOW.FSM is not necessarily the best solution for a problem this size, but its benefits grow as the problem space does. The benefits you're getting are:- state transition logic is all in one place, and can be changed without affecting correctness of state machine interpreter, which can also now be unit tested- significantly faster now we're not doing string comparisons- when state space gets really big and hard to manage, we can write a GUI tool for our levels guys to manage the transition tables (which are just data)Further refactoring opportunities:- push the reaction code into the Teacher object, so all we do is tell it its state is now "INSANITY" or whatever, and it handles setting all its internal shit we shouldn't need to be worrying about. Now we can have different Teacher objects that react in different ways, but we don't need to treat them any differently in this state code.
>>865620>1st year computer science student hereI highly recommend reading "head first design patterns": https://www.oreilly.com/library/view/head-first-design/0596007124/ch01.htmlA "design pattern" is a language-agnostic idiom that helps you solve a specific problem you'll encounter whilst wiring code. Whilst an algorithm is "what you're doing", a design pattern is "how you're doing it"; if an algorithm is a recipe, a design pattern is a clever way to lay out your stuff on the worktop.A lot of the problems in this code could benefit from the application of design patterns; specifically the chapter about encapsulation and inheritance amongst ducks.
>>865741I'm sorry, but what is the difference between a hash and a dictionary?
>>865620You are simply checking possible strings, this block therefore is more like a table, it's not program but information. Don't try to shorten information just to get fewer LOC, you have to put those strings SOMEWHERE, like you could put them into a container (array etc) and then just check the entry in the block - but that is just a relocation, you don't save one LOC with this, it just removes some text IN THIS BLOCK.And for gods sake, don't try to build an finite state machine for basic information! Nested ifs are fine, and the switch-case statement (if your language supports it) is literally just a rewriting of it, the compiler retranslates into the exact same nested conditional jumps.
>>865773Dictionary has all the accessory functions already written for you, but also a dictionary just specifies that you can feed keys in and get values out, it doesn't specify what algorithm it's using.A dictionary may use a hashtable which would use a hash, but it might use something else entirely. It might even use a different algorithm at runtime depending on how many entries are added to it. For example, if you only add eight entries, it might choose to use a simple linear search because that's actually quicker for n=8 even though it's slower asymptotically.The main point being that dictionaries have a lot of corner cases, and you don't want to be writing your own dictionary when there's already one that's already considered them.
>>865783Some programming languages use this strange term 'hash' to refer to this thing you call 'dictionaries' and using a 'hash' does not mean you will be a writing a whole in-memory key-value store from the ground up.
>>865777>Don't try to shorten information just to get fewer LOC, you have to put those strings SOMEWHERE, like you could put them into a container (array etc) and then just check the entry in the block - but that is just a relocation, you don't save one LOC with this, it just removes some text IN THIS BLOCK.>LOC>LOC>LOC>LOC>LOCYou're not considering the right metrics. You push out data from code to improve readability, testability, maintainability and separation of concerns. To address your specific example, pulling the strings out a data structure now means it's easy to read the strings from a file, or have them injected at runtime, or reuse our code for other entities we want the same "stimulus --> response" behaviour from just with a different set of responses and stimuli. It's easy to write unit tests so we know the code still does what it should be doing. It's easy to see what the logic is, because it's all there in one place, and it's easy to change it because we don't have to touch the code and the code is protected by a test framework."35 if statements" doesn't get a pass just because it's the "default". It's a deliberate design decision just like any other, and it has costs as well as benefits. The chief benefit is development time, and the chief cost is maintenance time, so the main reason to select it as a solution would be YAGNI.>don't try to build an finite state machine for basic information! Nested ifs are fineHowever you model it, what you're modelling is a state machine, this is a simple fact of the game's design. If you look at the picture in OP, what do you see? A (badly-implemented) state machine. Is it worth modelling the state machine as a state machine? That's where your skill and judgement comes in. It's reasonable to assume that this pattern appears dozens of times in a game like this, in which case using transition tables and an interpreter makes sense.
>>865789>Some programming languages misuse this strange term 'hash' to refer to this thing you call 'dictionaries' and using a 'hash' does not mean you will be a writing a whole in-memory key-value store from the ground up.Cool, good to know. If I'm ever conversing about this strange programming language, I'll bear that in mind, otherwise I'll continue to use "dictionaries" to refer to dictionaries, "hash tables" to refer to hash tables, and "hashes" to refer to hash functions, as is common and correct usage.
>>865794Hash here is short for hash map, if you must know.
>>865777>the switch-case statement (if your language supports it) is literally just a rewriting of it, the compiler retranslates into the exact same nested conditional jumps.No, an actual switch statement compiles into a goto into a trampoline table, or hoists all your statements into a function it writes itself, which is why you can only switch on integers, enums, etc. not on strings.Pic related, it's the compiler hoisting six cases that are really just the same assignment with different values into a single table lookup.
>>865795So does your "hash map" dictate that the underlying implementation use a hash table? If so, it's not the same thing as a dictionary, and if not, it's a bad name.
>>865798I would suppose an associative array that is implemented through the use of a hash function would automatically be called a hash, hash map, or hash table. I find it hard to fathom why anyone would choose to call it something else.
>>865804I would agree with you. But what about an associative array that isn't implemented through the use of a hash function? Wouldn't it be a bit silly to call that a "hash map", just because it has the same interface as a hash map?
man I just wouldn't check for it at all, maybe like pass a number to a function that checks a list of all possible endings? you could even use an array, I just heavily dislike to check for things.you could use a case statement I guess, I wouldn't ree if I saw that in someone's code.
I'd use Rust