1

As suggested by Uncle Bob in his book "Clean Code", I am actively trying to keep my functions small and readable.

However, I often encounter arguments drilling when I try to refractor a big function into smaller ones.

For example,

func bigFunc(input) {
  funcState := ...
  for {
    smallFunc(input, funcState)
    anotherSmallFunc(input, funcState)
  }
}

Logically, the two small functions operate differently, yet, they require the same piece of state. Is there anyway to rectify / avoid this issue?

6
  • 4
    Where's the problem? Why do you think that must be avoided? What would you say is Uncle Bob trying to achieve by doing this? Motivations matter. You are looking for solving something that could be motivated by personal (subjective) preferences, like readability. U.B states that he got many ideas from Kent Beck, who has been sharing with the community his particular point of view about coding. The community, in return, have turned these into dogmas, rules, principles, etc...
    – Laiv
    Jun 8, 2022 at 7:36
  • @Laiv The problem with argument drilling is that it can easily lead to violations of "keeping the arguments list short", a principle that U. B. emphasized in the same book as well. It seems rather contradicting if two principles cannot co-exist. I am very fond of the idea of writing something that is concise and easily readable and I believe by following (at least for now) his advice is the best thing I can do for now.
    – CheeseS
    Jun 8, 2022 at 13:40
  • a principle that U. B. emphasized Again. Who is coding? You or U.B? The only thing U.B has done is share his "particular" point of view about coding and he calls it "Clean Code", but Clean code is not a compendium of principles. That's why I'm afraid of you trying to solve a non-existing problem. As @RoberHarvey answered, there're different ways, you choose according to pros-&-cons or personal motivations. For example, Kent Beck likes symmetry. Symmetry in the names, number of arguments, return types, etc. None is a "principle", he stated that he likes because of the aesthetics.
    – Laiv
    Jun 8, 2022 at 15:14
  • @Laiv While your point is certainly valid, I am afraid I don't trust my personal judgment in this matter due to my lack of experience. Is strictly following someone's advice / opinion the best thing to do? Maybe not. However, before making a hasty judgment and deviate from such advice, I conclude that it's best for me to at least gain better understanding of his "principles" first.
    – CheeseS
    Jun 8, 2022 at 17:27
  • 1
    @JacobRaihle I am asking about potential deeper "chains" of argument drilling. The example above fails to deliver that. However, the approach to debunking such chains should be general meaning that the technique can be applied at any level, at least this is what I hope.
    – CheeseS
    Jun 10, 2022 at 19:29

1 Answer 1

7

There are a number of approaches you can try:

Use private class members to pass your data. Of course, that negates some of the benefit of passing your parameters to the functions directly. Like most things in software development, it is an exercise in tradeoffs.

Another way to do it is to use a closure. A closure captures the environment from where the function is called so that those variables become available to your function. You should only read those variables, not write them. This practice is usually associated with functional languages, partial application and currying.

Finally, you can pass a single object containing multiple pieces of data as a parameter.

1
  • Re. class members - for a long time I wondered why OOP was necessary, then, after having a code with lots of argument drilling everywhere, I finally noticed one real use-case for that - having class members definitely help for this particular case. 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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