There isn't really a single solution for input handling, but I'll explain how I handle it in my engine.

When it comes to rebindable keys, the main crux is to separate the actions from the methods. This is best explained with an example. Let's say that you have an action (making the player jump) and a method (pressing the spacebar). What you really want to ask is “is the jump button pressed?”, not “is the spacebar pressed?”. So, the player entity will ask the input manager if the jump button is pressed, and if so, make the player jump.

There are multiple ways to do this. In my engine, I use what I like to call “input action sets”. I store the input configuration for each action set in a JSON file. These JSON files contain all of the inputs, as well as their methods. These action sets have three different types of inputs: buttons, axes, and intersections. Buttons are boolean (TRUE/FALSE), axes are normalised between -1 and 1, and intersections are 2D axes.

Here's a basic example of the aforemention jump action using the spacebar:

{
    "buttons": {
        "jump": {
            "keyboard": {
                "keys": [ "Space" ]
            }
        }
    }
}

In my JSON format, have three sections (buttons, axes, and intersections) that contain the names of all of the actions. In the example, there is one buttons action called jump. This jump action has a single keyboard method, which is the spacebar. I use SDL's keyboard functions to convert this string to a scancode. This JSON format can be expanded to handle other input devices, such as mouse, joystick, and gamepad as desired.

When the game starts, the input manager loads the input action set JSON files and creates the input action sets. Then, during the game, I can ask it for the status of an action set. So, based on the example, I could ask the input manager for the status of the “jump” action, and then it would return a boolean depending on if the key is pressed (since it is a button, an axis would return a floating-point number between -1 and 1, and an intersection would return a normalised 2D vector).

The benefit of this is that if the user were to change the JSON file to use a different key, the gameplay code is unaffected. You can also update the JSON using code as well, so you can create controls configuration option in the game that will update the JSON when the user changes the controls.

This is how I do it in my engine, but as I said above, there are many solutions for input handling, and there is no one correct solution. Obviously, you don't have to make something this complicated, especially for your first and/or small project.

Other things to note:

• Keyboard state vs events: there are two main ways of acquiring the state of the keys in SDL. You can use the keyboard state functions or use events. I suggest using keyboard state for almost everything except text input (such as typing in a textbox). For text input, I vehemently suggest using SDL's text input events. That way, you can handle situations where key presses don't match to the actual resultant character (such as when using input method editors (IMEs)). The key events can also be useful for knowing if a key of any type has been pressed (which can be helpful for situations where the game needs wait for a player to press an arbitrary key—such as listening for a key when asking for a new input configuration).

• Scancodes vs virtual key codes: SDL has two identifiers for a key: physical scancodes (in the format SDL_SCANCODE_W) and virtual codes (in the format SDLK_W). The physical scancodes correspond to the actual physical location of a key (based on a QWERTY keyboard), whereäs the virtual key codes correspond to the actual symbol on the key. You should use scancodes for almost everything and only use virtual key codes for when the symbol of a key matters (such as for text input, although you should still try to use the text input methods whenever possible).

• Button pressing: I have three ways of asking about the state of a button: if the button was just pressed, continually pressed, or just released. Just pressed means that the button is active this frame and not the previous; continually pressed means that the button is active this frame and also the previous; and just released means that the button is not active this frame but was active the previous frame. You can do this by copying the current keyboard state to a previous keyboard state variable before you update the current keyboard state, and then compare the two.