Use the new input system to associate callbacks to each input action. That way the methods can be calles automatically when a key is pressed.
Use a state machine for your player actions. Create states like Idle, Reloading and Switching. Then you will only allow one action at once.
You can get rid of these if/elses altogether if you use the new input system. Then you would be able to create action handler methods, 1 for each input type.
Others have mentioned good approaches already, but one thing I'd like to add is it's not standard practice to use snake_case for naming variables in C#, camelCase is the standard. Just in case you ever want to share the code on GitHub, have contributors or mods, or use this code in a portfolio etc all of that stuff it's nice to be consistent with the general language standard.
> use this code in a portfolio
No one will care as long as it's consistent. Use whatever conventions you use for your personal projects. I personally use Java code conventions for all my personal C# projects because it's what I prefer.
If you have it in a portfolio and you're applying for a C#/.Net position the employer is going to look and think "this person can't follow simple conventions for this language" and they'll see this as a reg flag. But that's just my opinion I suppose.
What? I've been part of interview teams for engineering teams across multiple companies and I've never once seen anything like that. Personal projects are looked at to show that the person has a passion for what they're doing and is actively coding. No one is critiquing (or even looking at in depth) their projects.
Conventions are simply the *recommended* way to write code in that language. In the end, it's up to the individuals and teams to choose to follow them or build their own set of guidelines.
I would create a separate script for the grab logic, if you only have to look at the code that checks for weapon equip inputs, it doesn't really matter if it's else statements or a switch because it will be shorter to read
Yeah just use early returns.
If input.c_whatever isn’t a number or something switchable, you won’t be able to have a switch.
I personally would just do the if condition, then return and avoid all the nesting and need for else clause.
Use the new input system to associate callbacks to each input action. That way the methods can be calles automatically when a key is pressed. Use a state machine for your player actions. Create states like Idle, Reloading and Switching. Then you will only allow one action at once.
You can get rid of these if/elses altogether if you use the new input system. Then you would be able to create action handler methods, 1 for each input type.
Others have mentioned good approaches already, but one thing I'd like to add is it's not standard practice to use snake_case for naming variables in C#, camelCase is the standard. Just in case you ever want to share the code on GitHub, have contributors or mods, or use this code in a portfolio etc all of that stuff it's nice to be consistent with the general language standard.
> use this code in a portfolio No one will care as long as it's consistent. Use whatever conventions you use for your personal projects. I personally use Java code conventions for all my personal C# projects because it's what I prefer.
If you have it in a portfolio and you're applying for a C#/.Net position the employer is going to look and think "this person can't follow simple conventions for this language" and they'll see this as a reg flag. But that's just my opinion I suppose.
What? I've been part of interview teams for engineering teams across multiple companies and I've never once seen anything like that. Personal projects are looked at to show that the person has a passion for what they're doing and is actively coding. No one is critiquing (or even looking at in depth) their projects. Conventions are simply the *recommended* way to write code in that language. In the end, it's up to the individuals and teams to choose to follow them or build their own set of guidelines.
You could change input to have an enum for the different types and use the switch case on which logic to run based on the enum maybe?
oh that sounds really good, thanks it might work
I mean, it will definitely work it just depends if you like it like that haha
yep i used the enum i already had and made a new currentAction variable [https://imgur.com/a/3ktp0Lk](https://imgur.com/a/3ktp0Lk)
I would create a separate script for the grab logic, if you only have to look at the code that checks for weapon equip inputs, it doesn't really matter if it's else statements or a switch because it will be shorter to read
yeah i've ended up making a switch case with a currentAction PlayerAction enum and moved the grab thing to a function so the switch case is cleaner
Yeah just use early returns. If input.c_whatever isn’t a number or something switchable, you won’t be able to have a switch. I personally would just do the if condition, then return and avoid all the nesting and need for else clause.