My lead doesn't like commented code

Boss, look at the code. I didn't comment it. Why did you reject the check in?

---

        public void Foo()
        {
 
#if false
            Console.WriteLine("This is a sample which will never get executed");
#endif
            Console.WriteLine("Current code goes here");
        }

---

I had hard time with people who doesn't understand the problems with the commented code. According to them it needs to be there because that functionality might be requested by business in future.

My answer to them as a software craftsman is to use any source control system, if they are not using. But now a days there will be no company in the world which doesn't use source control for development. At least they can host in free Github account. Sometimes I had to show dev leads, how to get history from TFS.

Another argument people put forward is the reusability. Don't confuse with real reusability of code. This is about going back to previous logic after some time period. They argue that if the code is commented,it can be simply uncommented. If we delete, we have to go back to history and take it back. Sometimes, new developers will not be knowing that the same had been deleted in the past and they will write the old logic again. My answer is to use dependency injection. This still feels too technical to most of the people. But its very simple to those who had tried it at least one time. Follow the single responsibility pattern religiously to split up the code to small units and compose the application by injecting dependencies. if there is a change requested, have that logic in a new class by implementing required interface and change the dependency injection catalog so that the new change will take effect. Let the old class be there unused. We can use it in future.