You are absolutely right, as with most techniques on this list, you need to be sure we don’t go overboard. It comes down to knowing how to use these techniques efficiently.

I understand the point you’re making (and agree), but I think the way you’ve stated it is misleading. The goal is to make sure methods perform a SINGLE logical operation or task that is easily described [i.e. high cohesion]. Doing this usually LEADS TO flexibility, because the code is highly portable and re-usable, but the methods themselves are not necessarily flexible.

Creating methods to be flexible can often REDUCE cohesion. Using your example, for instance, I might create a more flexible method like this:

function getName(employee, outputType) { … }

where outputType contains some flag like ‘show_alert’ or ‘inner_html’ that my code uses to pick alternate means of displaying the data. This code is certainly flexible and can easily be extended, but it is obviously a poor design choice. Your second getName() example shows the correct approach, which provides flexibility by decoupling the mechanism of obtaining the name from the mechanism using the name.

I know we’re saying the same thing, I’ve just seen too much bad code written by developers focusing on ‘flexibility’ at the expense of other, more important concerns :)

Comments also be used to separate off blocks of code. Every syntax highlighting editor will draw the comment line in a separate colour so tactical commenting can also be a good, visual way of breaking up the code.

You can go too far though, commenting every single line makes code far more difficult to read.