As mentioned by Gleade, the event should be checked
within the pollEvent loop. This is because otherwise you would be checking the final event if there are more than one, skipping and ignoring potentially important events. Also, if there are no events, the event is invalid and checking it could result in unexpected results.
The linearity of this code is also quite difficult to read. Since each block of code represents the current state of the program, I would recommend looking into a form of state management.
The simplest is to use an enum to track which state you are in and then "switch" the code based on that enum.
Moving on from there, you can implement a simple Fixed State Machine so that code states are separated and clearer.
From there, you may then want to consider using a stack of states and "peel them off" to go back and/or have the ability to have multiple states working at once.
Clears the window straight after you display the back buffer that you've drawn to. Therefore those draw calls are redundant.
Although often the clearest way to use clear, draw and display is to place them in that exact order, it doesn't actually matter where they go in your code, just as long as they go in that order.
In this case, once everything has been drawn to the back buffer (draw), the back buffer is swapped with the front (display). Then, the back buffer (new one - was the old front) is cleared - not affecting the stuff just drawn as it's now on the front.
This way can be less clear but it isn't as bad as you might this. However, the fact that sometimes the stuff is drawn without it being first cleared (even from the previous code) means that the first frame could be garbage.
One thing to note is that there should be a clear for each display (usually).
