TLDR
Yes. You should clean up and refactor your code IMO.
Thoughts
I’m going to address this out of order somewhat, but I wanted to get the answer out of the way.
Also, everyone needs to refactor. I’ve been doing this professionally for almost 30 years and as an amateur for almost 40. Over the past two days I’ve been doing a massive refactor of the game I’m getting paid to work on. I was banging my head against where I store multiplayer skins and had to rip out a bunch of code. It’s now much more streamlined, I eliminated a number of annoying bugs, found some new ones because of it and fixed those too.
Refactoring can be fun if you let it, because when you’re done you’ve accomplished something, and your code is clearer and you know it better.
If it works, it’s not bad code - it’s working code that could be improved. Don’t get down on yourself. You were learning to code inside a project.
First Things First
Put your code on GitHub or GitLab before you do anything else. I’m actually been becoming a fan of GitLab again of late, as I’m using it for a project and I like their ticketing system. Do this before you go into your giant file and mess things up and create an existential crisis for yourself.
I assume you haven’t done this, because the typical way to share a file that big is a GitHub link. I cannot stress this enough, so I’m going to say it again: Put your code on GitHub before you do anything else.
Formatting
Take a look at GitHub - Scony/godot-gdscript-toolkit: Independent set of GDScript tools - parser, linter, formatter, and more and use the Formatter. It will help solve your spacing issues.
Formatting
First, your code doesn’t look that bad. Yes, I have things to say, but like I said, if it functions you’re doing good.
- You can use Ctrl + Shift + F to find every instance in every file in your project and change things all at once. This will save you time.
- Use
snake_case for variable names. For example, currentState should be current_state.
- A convention I like to follow for both
bool value and functions that return bool is to start the name with “is”. So airdashing would become is_air_dashing (also following the advice from above.) It will make your code more readable because when you test it your code will read: if is_air_dashing: Adding “is” to the front helps not just with readability, but also helps with naming. It can help clarify what the name of the variable should be, and also helps with questions like “What verb tense should this be?”
- Don’t abbreviate in variable names.
jumpstr is pretty clear, but jump_strength is clearer and then I don’t have to think in my head “Jump string? No, jump strength.”
- This is a choice, but I recommend strongly typing everything. Go to Project Settings → General Tab → Debug → GDScript → Untyped Declaration and change it from Ignore to Warn. You are going to get a LOT of warnings, but it won’t prevent your game from running, and they are all an easy fix. If it’s overwhelming, you can turn it back off.
- The formatter should take care of this, but
const should be at the top of the file, not in the middle of the variable declarations. Similarly, all @onready variables should be at the bottom of variable declarations.
Refactoring
There isn’t enough information in that one file to allow me to make specific suggestions on refactoring. However, what you want to do is take an object-oriented approach. Ask yourself, “Could this function be its own object or file?”
A good place to start would be movement. Create a Node as a child of your CharacterBody3D and call it Movement. Move all your movement, sprint, jump code into a script attached to it, and then hook everything back up. You’re not changing anything about the code, except how it’s called. Movement will need a reference to the player. Then the player needs to call movement.movement(self) inside _physics_process. (Or something like that depending on the decisions you make.)
Ultimately refactoring is about chunking your code into digestible, logical bits that are easier to wrap your head around.
State Machine
After you’ve refactored, you can think about using a state machine. I’m going to recommend you try using my State Machine addon because it’s well documented and should get you going rather quickly. Plus if you have questions about it, you know someone who can answer them. 
Conclusion
Refactoring is about making everything run smoother, both the actual code, and your use of it as the developer. We all “just make things work” at times for various legitimate reasons. Life is messy. Refactoring just helps us realize how far we’ve come. Enjoy it!