Actually this does matter and it's a good question. I've had experience with some devices when the blank space isn't forced as an entity with
it would render content incorrectly if the space existed in something like a span tag.
foo bar renders as
foobar when coded as:
<span class="bold">foo </span>bar
Some applications, for example InDesign, on HTML and CSS export it as:
<span class="bold">This is Friday</span>
Overall, this can be up to the designer but it should be adopted in the workflow for parity. I would encourage you test how it will be treated on the finish product since it can play a factor in your development. So to answer your question, when I develop using HTML I do not include ending or beginning spaces inside my span tags since I've had experience with them being ignored by the rendering engine from a few devices.
If you choose to include spacing at the end or the beginning inside of your tags I would encourage you to code as such:
<span class="bold">foo </span>bar
From a developmental side, you should take into consideration parsing behavior and usability. For instance, if you develop a dictionary and plan to parse out certain elements that could be incorporated a particular section if you include beginning and ending spacing in something like span tags or in an element it could have drastic results on the ending.
You can downvote if you think it was appropriate but the fact still remains that this can't be cited as a preference. Several devices on the market ignore how spacing is performed, and the purpose of my answer was to mention that the avenue of which the content would be viewed should be a factor in the decision and how it is created. Personally, when I develop content, I take into consideration how it's viewed in an app, printed, or on a site, and such the OP should consider that as well.
After I'm told this isn't for web it still comes down to the medium in which going to produce an issue. If not then do it anyway but adopt parity. If it is, then do it in a way that it comes out correctly.