It is incredibly important to avoid putting tag-firebreaks in the code base — anything that stops a new developer from being able to navigate from symbol to definition, or from definition to all uses of that function.

A couple of examples:

  ACTIONS = {
    “swim”: Swimmer,
    “skate”: Skater,
  }
  
  # …pages of code…
 
  def f(action, *args):
    …
    mod = ACTIONS[action]
    mod(*args).do()

This pattern doesn’t do anything particularly wrong other than anyone on a code safari shoe arrives at f will find it doesn’t contain the symbols for either Swimmer or Skater. Sure, ACTIONS is only a hop away, but what if the class name was derived from a string?

The fact that the action implementations are chosen at runtime also makes life a bit awkward but the primary issue is not being able to immediately see what actions there are, nor be able to jump to their implementations.

Another one is calling shell scripts. We all have projects, I’m sure, where we have to shell out to some common legacy tool:

  def f():
    run(“legacy.sh”)

  def g():
    run(“legacy.sh”)

The simple act of wrapping the script in a native function does wonders for making it easier to find, especially for the poor, sacred soul who deprecates it from the codebase one day:

  def f():
    run_legacy()

  def g():
    run_legacy()

  # …pages of code…

  def run_legacy():
    run(“legacy.sh”)

Any unfriendly pattern that breaks tag-hopping / IDE-integration is yet another small chafing of your colleagues‘ productivity. Think twice before you introduce that YAML file which defines behavior, instead of implementing it natively — your friends (and their jump-to-definition muscle memories) will thank you.