First, you may be interested in this book.
But I want to know exactly when I should be using void, and when I should be returning a variable.
You should take the following with a grain of salt, as I'm one of the less experienced coders here, but it sounds to me like you're getting too caught up in the idea that there's a "right" way to do everything. The only real consideration is what you need from your code. If you don't need a function to return a value, then return type void is appropriate (this type of function is often called a routine). That the possibility exists to return an integer doesn't mean that using a routine is bad. But if you can't think of a reason or design to use an integer return value, then you don't need one. There's not exactly a rule that you're violating, just a need you don't have and an approach you're not using.
Additionally, I don't think you're in the "basic concepts of programming" realm any more. This would also explain why you aren't finding the answers you want in tutorials and books. A major design approach isn't basic, and a book that tells you what a float is probably assumes that you aren't ready for that information. And there is enough contention in the design and architecture theory space that you shouldn't count on there existing a canonical, objectively "best" practice all the time.
I know that it's more effective to use a single instead of a double when you're working with a smaller number, but why?
From this line, I'd say that you don't know that a single is better suited to a small number than a double at all. You've heard it, but haven't evaluated the statement. Think about it. Google things you're unsure about, like "what exactly is a double? What is a single?". When you get stumped, which will happen from time to time, this and other communities exist so that you can ask a clear, pointed question.
If you've reached the extent of what the average programming tutorial can teach you, then you've reached the point where you will need to take a more active role in developing your knowledge and skills. As you learn more, there is less pre-packaged material (like tutorials) available to tell you what you want to know. And while research is good, experimentation is even better. If you're unsure about something, slap together a test program that will let you examine the question yourself.
Your knowledge base builds up one piece at a time. There isn't some pile of information that can be dropped onto you that will do what you're asking.
in terms of coding and their core foundations and reasoning behind its basic principles. Just the silly things that nobody bothers to elaborate on as I explained above.
Bolded section: That's the stuff careers are made of. Professional computer scientists conduct meticulous studies and write formal papers about programming theory. If you're looking for video tutorials on this sort of thing, I think you're going to be frequently disappointed.
The rest: They aren't "silly little things". They're foundational computer science, and a book on them is more likely to be a CompSci 101 textbook than anything else. The people who "bother to elaborate" on them are professors and other instructors. jbadams' post has good information about how you can get to that kind of information.