Recently, I was writing a test method similar to this:

/**
 * SOME_FEATURE is a constant that identifies a feature the application provides if enabled
 */
void transferMoneyTest() {
	withEnabledFeature(SOME_FEATURE, () -> {
		// line one of the test method
		// line two of the test method
		// line three of the test method
		// line four of the test method
		// line five of the test method
		// line six of the test method
		// line seven of the test method
	});
}

One of my colleagues pointed out that it is a best practice to place lambda code in a distinct method when its size exceeds a certain threshold (e.g., 2 or 3 lines). Hmm, I thought to myself, he is right, but there are exceptions – and this is one of them.

But why is that an exception? Well, let’s see other similar examples:

/**
 * "transactional" method provides the ACID transaction context for the lambda 
 * execution (is the equivalent of e.g., @Transactional from Spring Framework)
 */
public void transferMoney() {
	transactional(() -> {
		// line one of the method's implementation
		// line two of the method's implementation
		// line three of the method's implementation
		// line four of the method's implementation
		// line five of the method's implementation
		// line six of the method's implementation
		// line seven of the method's implementation
	});
}

/**
 * "preAuthorize" method provides the security context for the lambda 
 * execution (is the equivalent of e.g., @PreAuthorize from Spring Security)
 */
public void transferMoney() {
	preAuthorize("hasAuthority('permission:write')", () -> {
		// line one of the method's implementation
		// line two of the method's implementation
		// line three of the method's implementation
		// line four of the method's implementation
		// line five of the method's implementation
		// line six of the method's implementation
		// line seven of the method's implementation
	});
}

/**
 * Let's suppose it doesn't make sense to use *synchronized* at the method level.
 */
public void transferMoney() {
	synchronized (merchant) {
		// line one of the method's implementation
		// line two of the method's implementation
		// line three of the method's implementation
		// line four of the method's implementation
		// line five of the method's implementation
		// line six of the method's implementation
		// line seven of the method's implementation
	});
}

All the above examples show some code blocks executed in a particular *context*.
Would the code be more readable if one took the below approach instead of a lambda expression?

public void transferMoney() {
	transactional(doTransferMoney);
}
// ...
// a
// bunch
// of 
// other 
// public, 
// protected, 
// and 
// private 
// methods 
// go 
// here
// (i.e., there's a big distance between transferMoney and doTransferMoney)
// ...
private void doTransferMoney() {
	// line one of the method's implementation
	// line two of the method's implementation
	// line three of the method's implementation
	// line four of the method's implementation
	// line five of the method's implementation
	// line six of the method's implementation
	// line seven of the method's implementation
}

Well, the transferMoney is much shorter and hence easier to read; the problem though is with *what* is left to read:
the user reads a method meaning “transfer money” (i.e., transferMoney) which does “transfer money” (i.e., doTransferMoney) in a transactional fashion (well, at least he learns something about the *execution context*).

This is silly; in the above situations, I would rather keep the doTransferMoney content in transferMoney method because it’s easy to spot the distinction between the *execution context* and the *behaviour* implementation; moving the *behaviour* in another method brings no benefit.

This does not invalidate the rule of thumb that a lambda expression larger than 2-3 lines is best to be moved to a distinct method. In most situations, the *behaviour* is mixed with the lambda expressions hence the reader has to collapse the lambda expression to see the rest (i.e., the *behaviour*). It’s not the same for transferMoneyTest and the similar examples above, because collapsing the lambda expression means hiding the *behaviour* the user intends to view.