For example, if you write a function to read a file of numbers into a vector (eg, readVector(v)), that's all the function should do. If you know that you also need the sum of the numbers, Here are three ways to solve the problem of reading a vector and summing the elements.
// CRIMINALLY BAD. Not obvious that sum is in global variable. readVector(v);Not only does this function do more than one thing, but the name and call give no clue that it is doing more. The hidden reference to a global variable also increases the coupling (connections between parts of a program), which is bad.
// BAD. Function does two things, and one is unobvious. x = readVector(v);This is bad because it isn't obvious from that name that a value is returned or what that value might be. It does reduce the coupling and at least it is obvious in this use that it does return a (unknown) value.
// POOR. Understandable, but not very reusable. x = readVectorAndComputeSum(v);This clarifies the processing, but doesn't produce simple, reusable building blocks.
// GOOD. The two actions are separated and given good names. readVector(v); x = sumVector(v);This is better because each function does one clear thing (ie, is cohesive). These function building blocks are also much more likely to be reusable. But what about the efficiency of this solution. Isn't the extra function call less efficient? Yes, but the amount is so small that it isn't worth more than a few nanoseconds. If this was in an extremely high performance loop (eg, rendering real-time graphics), then it might be worth thinking about optimizing. What you should optimize for is the readability of programs -- programmer (ie, your) time is worth much more than a few machine cycles. And the extra time you take to type in an extra function is easily repaid in having a simpler program to work on.