The names are not meant to be abstract (the data types can, of course, can/should/could be).
As for variable names, if in function1 you call a parameter "size", then calling it "want" in another function is just confusing. Call them size in both. If in function1 you have something called "data" and that function1 calls function2 then make sure that if function2 also has a parameter called "data" that they're the same type. Doing otherwise is bound to cause confusion. Naming a parameter "what" is no help at all.
Going back to data types being abstract, you don't have to obfuscate the code to make them abstract. Is std_list an abstract data type of a linked list? I have no idea. Abstraction is generally not about providing bare bone information, to the caller, it's about providing no information at all. But in the implementation of the ADT you need to have the information and the information needs to be readable by a human. If it's not readable by a human then it cannot be maintained.
As for the early returns and stuff... I know it's tempting, and in some cases it can lead to better code. But the problem is that if you have heaps of early returns it's difficult to understand the state of variables if the program execution gets past the early returns. I.e. If you have, say, 6 early returns based on whatever conditions then it's really, really hard to reason about the state of variables and conditions that have been met if the early returns do not happen. The early returns (although they have their place) make the code unstructured and this lack of structure is what makes things hard to understand.
Edit: Just to be clear, I'm not saying this just to be mean or whatever. I'm saying it because I think if you adopt better approaches you will be a better programmer and you'll also write code that's more maintainable