My boss asks me to stop writing small functions and do everything in the same loop

there are other problems

Neither code is good, because both basically bloat the code with a debug test case. What if you want to test more things for whatever reason?

phoneNumber = DEV_PHONE_NUMBER_WHICH_CAUSED_PROBLEMS_FOR_CUSTOMERS;

or

phoneNumber = DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY;

Do you want to add even more branches?

The significant problem is that you basically duplicate part of your code and thus you aren't actually testing the real code. You write debug code to test the debug code, but not the production code. It's like partially creating a parallel codebase.

You are arguing with your boss about how to write bad code more cleverly. Instead, you should fix the inherent problem of the code itself.

dependency injection

This is how your code should look like:

phoneNumber = headers.resourceId;

There's no branching here, because the logic here doesn't have any branching. The program should pull the phone number from the header. Period.

If you want to have DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY as a result, you should put it into headers.resourceId. One way of doing it is to simply inject a different headers object for test cases (sorry if this is not proper code, my javascript skills are a bit rusty):

function foo(headers){
    phoneNumber = headers.resourceId;
}

// creating the test case
foo({resourceId: DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY});

Assuming that headers is part of a response you receive from a server: Ideally you have a whole test server that delivers headers of various kinds for testing purposes. This way you test the actual production code as-is and not some half duplicated code that may or may not work like the production code.

There is no "right" or "wrong" answer to this. However, I will offer my opinion based on 36 years of professional experience designing and developing software systems ...

1. There is no such thing as "self-documenting code." Why? Because that claim in completely subjective.
2. Comments are never failures. What is a failure is code that cannot be understood at all without comments.
3. 300 uninterrupted lines of code in one code block is a maintenance nightmare and highly prone to errors. Such a block is strongly indicative of bad design and planning.

Speaking directly to the example you provided ... Placing isApplicationInProduction() into its own routine is the smart(er) thing to do. Today that test is simply a check of "headers" and can be handled in a ternary (?:) operator. Tomorrow, the test may be far more complex. Additionally, "headers.resourceId" has no clear relation to the application's "in production status;" I would argue that a test for such status needs to be decoupled from the underlying data; a subroutine will do this and a ternary will not. Additionally, a helpful comment would by why resourceId is a test for "in production."

Be careful not to go overboard with "small clearly named functions." A routine should encapsulate an idea more so than "just code." I support amon's suggestion of phoneNumber = getPhoneNumber(headers) and add that getPhoneNumber() should do the "production status" test with isApplicationInProduction()

Robert Martin's programming style is polarizing. You will find many programmers, even experienced ones, who find a lot of excuses why splitting up "that much" is too much, and why keeping functions a little bit bigger is "the better way". However, most of these "arguments" are often a expression of unwillingness to change old habits, and to learn something new.

Don't listen to them!

Whenever you can save a comment by refactoring a piece of code to a separate function with an expressive name, do it - it will definitely improve your code. Automatic refactoring tools make it easy, simple and safe to extract methods. And please, do not take people serious who recommend writing functions with >300 lines - such people are definitely not qualified to tell you how you should code.

Don't put everything in one big loop, but don't do this too often either:

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

The problem with the big loop is that its really hard to see its overall structure when it spans many screens. So try to take out large chunks, ideally chunks that have a single responsibility and are re-usable.

The problem with the tiny function above, is that while atomicity and modularity are generally good, that can be taken too far. If you're not going to reuse the above function it detracts from code readability and maintainability. To drill down into the detail you have to jump to the function instead of being able to read the detail inline, and the function call takes up hardly any less space than the detail itself would.

Clearly there is a balance to be found between methods that do too much and methods that do too little. I would never break out a tiny function as above unless it was going to be called from more than one place, and even then I would think twice about it, because the function just isn't that substantial in terms of introducing new logic and as such barely warrants having it's own existence.

It seems like what you actually want is this:

phoneNumber = headers.resourceId || DEV_PHONE_NUMBER

This should be self-explanatory to anyone who reads it: set phoneNumber to the resourceId if it's available, or default to DEV_PHONE_NUMBER if it's not.

If you truly want to set that variable only in production, you should have some other, more canonical app-wide utility method (that doesn't require parameters) to determine where you're running from. Reading the headers for that information doesn't make sense.

Let me be blunt: it seems to me that your environment (language/framework/class design etc.) is not really suited for "clean" code. You are mixing all possible kinds of things up in a few lines of code that should not really be close together. What business does a single function have with knowing that resourceId==undef means that you are not in production, that you are using a default phone number in non-production systems, that the resourceId is saved in some "headers" and so on? I assume headers are HTTP headers, so you even leave the decision about which environment you are in to the end user?

Factoring single pieces of that out into functions will not help you much with that underlying problem.

Some keywords to look for:

• decoupling
• cohesion
• dependency injection

You can achieve what you want (in other contexts) with zero lines of code, by shifting the responsibilities of the code around, and using modern frameworks (which may or may not exist for your environment/programming language).

From your description ("300 lines of code in a 'main' function"), even the word "function" (instead of method) makes me assume that there is no point in what you are trying to achieve. In that old-school programming environment (i.e., basic imperative programming with little structure, certainly no meaningful classes, no class framework pattern like MVC or somesuch), there is really not much point in doing anything. You will never get out of the sump without fundamental changes. At least your boss seems to allow you to create functions to avoid code duplication, that is a good first step!

I know both the type of code as well as the type of programmer you are describing quite well. Frankly, if it were a co-worker, my advice would be different. But as it is your boss, it is useless for you to go fighting about this. Not only that your boss can overrule you, but your code additions will indeed lead to worse code if only you do "your thing" partially, and your boss (and probably other people) keep on like before. It may just be better for the end result if you adapt to their style of programming (only while working on this particular codebase, of course), and try, in this context, to make the best out of it.