Let me take a crack at this,

Think of the risks you’re posing by accessing an array straight away.

• Do you know for SURE, it’s got data at the aforementioned index?
• Is that data in the format you want?
• If there was an Exception, like a null at that index, would your
  program be able to recover?

I cannot tell off the bat what language you’re using… but, in any language it’s a good idea to just double check the input of your functions before using them. This can save massive headaches when a codebase grows.

From a design point of view, there seems to be a problem here – you’re accessing a function that returns a set of values, take one specific value from it, and discard the rest.

Doesn’t this feel like a waste, retrieving values you have no use for? Wouldn’t it make more sense to replace get_array()[2] with a specific call, get_item(2)?

This entirely depends upon what you are planning on doing with the array and what you should/can do if the element you expect to be at a certain position isn’t there.

Frequently, when this is done, it is returning multiple values (such as a first, middle and last names) which are actually independent — the array is an ad hoc structure. The problem with this is that it isn’t defined anywhere, and so is fragile. If you add enums to make it less fragile, you’ve spent about as much time, for not much gain – better to just define a structure and be done with it.

That said, sometimes you have to consume a API where this has been done, in which case, directly accessing the value is fine if the contract says it will always be there.

If you don’t do anything with the returned value except access it once, putting it in a temp variable doesn’t gain you anything (except possibly during debugging, where knowing what result is passed to a function can be useful).

It is always good practice to separate your code’s IO from its internal computations. The coding-related StackExchange sites are littered with code that mixes Print (or Println or putStr or whatever is the local dialect) inside complex functions. This is bad practice.

In the case of output (as in your example), mixing output statements with computation tends to make the final output of the program dependent on the internal structure of the code. It then becomes difficult to alter that code without breaking the output. For example, you might want to print out a sorted sequence of lines; you happen to extract them from some structure which automatically sorts them, so you naively add print statements as you compute each line. This works. Then you switch to storing the intermediate calculations in a structure which doesn’t sort them. Broken output which requires you to remove the print statements, add a sorting step and then put the print statements after that.

If you separate computation from presentation, you don’t have this problem.

In your specific example, I don’t think either choice is good, because both might fail. Even if you get a valid array, what if it doesn’t have a second row? This is a problem you should resolve before your output step. Your second example is actually worse, because it doesn’t resolve the problem so adds a pointless extra step.

output=get_array()[2]
print output

Would be better. The retrieval of the data and its output can then be cleanly separated.