[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / vrpg / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/wsr/ - Worksafe Requests


Thread archived.
You cannot reply anymore.



File: gyubzyq87xmx.png (149 KB, 828x801)
149 KB
149 KB PNG
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 statement

I 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?
>>
>>865620
Build 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
>>865641
Erm, you can't switch on a string, because every complaint about nested if statements still applies just now the compiler is doing it.
>>
>>865620
See https://archive.nyafuu.org/wsr/thread/860339/
>>
I don't know wtf a YandereDev is, but you need to use a hash.
>>
>>865709
No, 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.
>>
>>865620
An 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/
>>
>>865620
You 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.
>>
>>865746
sup yandev
>>
>>865746
No, it's really bad:
>The code is readable
To a point; it's really quite flabby
>you can easily edit it
No. 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).
>>
>>865620
Pseudocode example of how to use a state machine
>1st year computer science student here
which 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.
>>
File: 004fig03.png[1].jpg (61 KB, 858x442)
61 KB
61 KB JPG
>>865620
>1st year computer science student here
I highly recommend reading "head first design patterns": https://www.oreilly.com/library/view/head-first-design/0596007124/ch01.html

A "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.
>>
>>865741
I'm sorry, but what is the difference between a hash and a dictionary?
>>
>>865620

You 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.
>>
>>865773
Dictionary 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.
>>
>>865783
Some 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.
>>
File: 007fig02.png[1].jpg (62 KB, 514x402)
62 KB
62 KB JPG
>>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
>LOC
You'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 fine
However 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.
>>
>>865794
Hash 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.
>>
>>865795
So 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.
>>
>>865798
I 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.
>>
>>865804
I 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



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.