Avoiding Footguns
Footguns are features or designs more likely to be misused, often leading to self-inflicted problems or bugs (“shooting yourself in the foot”). See a list of C functions?banned?in the git codebase for being footguns. Some more examples:
Avoiding footguns comes with experience — often, the footguns are perfectly legal code that can be compiled. Some languages avoid certain footguns (sometimes to introduce other ones). For example, garbage-collected languages remove one class of memory management footguns (at the expense of a GC).
Language-level footguns are probably the biggest class of footguns — e.g., default arguments are mutable in Python, useEffect without dependencies in React, not closing connections in a defer block in Go or the Drop trait in Rust.
Linters can sometimes catch footgun constructions and surface them as warnings. But the most effective way is just learning them.
Originally posted on https://matt-rickard.com/avoiding-footguns
SaaS Business Advisor and SaaS Angel Investor
1 年Good points. At my last company, after we witnessed users of our tool shooting themselves in the foot by trying to do (in our minds) surprising and counter-intuitive things, we put appropriate safeguards in place. In some cases, “bans” (you can’t do that, because…). In other cases big bold “are you SURE you want to do that? It would normally be a terrible idea to do that unless you are trying to achieve this specific extremely rare edge case goal...” The tool was significantly better for it. This topic reminds me of “poka-yoke” solutions which proactively prevent footgun damage in both manufacturing processes and in customer-usage contexts. https://en.m.wikipedia.org/wiki/Poka-yoke