Red Flags

Red flags in code are code structures that are generally a bad idea and should be reconsidered. That's not to say that they are never appropriate, but these are the sort of thing that should trigger a dev to stop and reconsider what's being done.

These are generally things that can cause maintenance or performance issues, though they're often not immediately self-evident.

Maintenance Headaches

Adding extra arguments to a function

When refactoring a function, it's best to add extra arguments to the end of the list of arguments, rather than the middle. Most languages are more forgiving of extra/missing positional arguments at the end of a function than the arguments in the middle breaking assumptions.

Consider this refactoring of a method

-callback(factor_injury_crashes, map)
+callback(factor_injury_crashes, injury_crashes, map)

In this situation, any calls which were overlooked by the refactoring will be feeding data intended for map into injury_crashes and likely choke due to the mismatch. If we add the extra argument to the end instead, we can avoid having issues in situations where calls to the method were overlooked, they will simply use the default value (which is likely the desired situation anyways).

-callback(factor_injury_crashes, map)
+callback(factor_injury_crashes, map, injury_crashes=[])

Magic variables

Variables that are used in functions/classes without passing them in and out, abusing the nature of soft scopes. These sort of variables can make it more difficult to pin down why and how an issue is happening.

It's generally a better practice to either pass variables in and out of functions as-needed or use an instance of a class to maintain the state of things cleanly.