Intuitively, I know that (in terms of a maintainable, understandable codebase) the following code is bad practice

var foo = fooFunc(barFunc(),wooFunc(chewFunc()));

and might be better stated as

var bar = barFunc();
var chew = chewFunc();
var woo = wooFunc(chew);
var foo = fooFunc(bar, woo);

This makes debugging easier, code more readable etc. etc...

Instead of personally spelling this out to co-developers, it might be better to lead them to an existing page that explains the perils of such a construct.

Is there an official term for this kind of anti-pattern?

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, user22815, user40980, user53019 Aug 13 '15 at 1:15

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    "Intuitively, I know... is bad practice" - eh? That kinda depends really. If wooFunc is an increment and barFunc and chewFunc are just getters, then your version is just clutter. The amount of flame generated by is tertiary operator good or unreadable?is beyond comprehension. This is just another version of it. Your company will have to decide on what balance of shorter code/clearer code you want to strike. If half your devs are entry level, clear is a definite yes. If your devs are used to read golfed code before bedtime - no point having them scroll through meaningless variables. – Ordous Aug 12 '15 at 18:25
  • 5
    I hate the second; more code = less readable = less maintainable often times. Semantic density is something that needs to be balanced, your first example has too much meaning in a small space - it's too semantically dense, your second example is not dense enough; it takes too much reading to gain an insight into the semantic purpose of the code. It's intuitive to strike a balance of semantic density in english: You don't stretch a statement across as many words as possible, and you don't smush it into it's most compact form because neither is very understandable. – Jimmy Hoffa Aug 12 '15 at 19:06
  • @Ordous It reminds me of the suggestion to break up long access chains onto multiple lines as a "solution" to Law of Demeter violations. – JAB Aug 12 '15 at 19:28
  • Keep in mind everyone that foo/bar examples don't always convey the same meaning. In a real program, those intermediate variables usually can have much clearer, more locally-meaningful names than the functions, which tend to have more generic names because they are shared. I agree, though, about readability if the variable names are only minor variations on the function names. – Karl Bielefeldt Aug 12 '15 at 21:06

The code form you want is called A-normal form (ANF); it is not always more readable, but it might be more easily tranformable inside compilers, and is useful for precise garbage collection (hence, many compilers are transforming the source code into some intermediate ANF). See also SSA form.

I don't believe that ANF is always more readable; on the contrary, coding with nested side-effect free function calls is often more easy to understand IMHO. But that is a matter of opinion, and of course depends upon the context. YMMV.

Of course, things may be different if some of the functions have significant (e.g. global) side effects, in particular because many programming languages do not specify an order of argument evaluation.

  • There are two main advantages to coding that way. You hit on the side effects: many languages have sequence points which help contain side effects. The other is debugging. Stepping through the single-line example in the question is awful. I would much rather have the expanded form while debugging. – user22815 Aug 12 '15 at 22:17
  • On the other hand, stepping into fooFunc is hard in the first case with many debuggers. – gnasher729 Aug 12 '15 at 22:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.