Frontend coding guidelines at my company

gistfile1.md

• Use TypeScript
• Expect the unexpected: yes, we use TypeScript, but you never know when things could go wrong
• Murphy's rule: whatever that can go wrong will go wrong
• Be liberal in what you accept, and conservative in what you give out
  • This is related to handling remote data
    • Some axioms
      • Never trust user data
        • Validate it
      • Allow them to give you just about anything
        • In HTTP, clients can decide what they want to give to you; do your best to parse as best as possible
      • Things shouldn't crash
      • Fail gracefully
      • Regarding TypeScript: use Zod
        • If using zod, does everything need to be "required"? Does everything need to be typed at all? Why not "unknown" and gracefully gain a clearer picture?
• Avoid default exports, unless a parent framework expects it
  • Reasons
    • Default exports can be accidentally renamed
    • Default exports could have us accidentally load in the same module more than once
    • Default exports are hard to refactor
• It's better to write testable code than to write tests
  • Write tests, but before that, write testable code; then write tests
• Avoid the use of any; it's a legacy feature for teams needing to migrate their code away from JavaScript onto TypeScript. If you need a top type, you should use unknown
• Use erasableSyntaxOnly for TypeScript projects; have things as close to JavaScript as possible
• Avoid any draft features of the ECMA262 standard
• Always format code in accordance to the Prettier configs
• Flat file structures are fine. Organizing things into hierarchies is overrated; do it if you really feel it helps you
• Don't bother with descriptive names; actions speak louder than variable names. What it does is more valuable than what it's claiming to value
• Use prettier so that:
  • We avoid debating the minutia
  • We have a standard when parsing code
• Reusable code is overrated; don't even bother
  • Avoid Hasty Abstractions (AHA)
  • Write Everything Twice (WET)
    • Just a heads up: this rule as worded is nonsense. But you have got to understand the context for why this is even relevant: it was created to fight overzealous efforts to minimize code duplication, when code duplication is perfectly fine. The overzealous effort to avoid writing duplicate code exists to avoid lazy reuse of code, that really could have been abstracted away
      • A good example where code duplication is fine is instead opting for idioms as opposed to function names.
        • If we're OK with using function names over and over again, then we should be fine using the same pattern of code over and over again. This is called idiomatic programming
          • Some people argue that idiomatic programming exists to let the compiler optimize a common code path, but nevertheless, the sentiment around idiomatic programming predates smart compiler optimizations
• Complex CSS classes are a red flag
• Composition over inheritance
  • This is more an aphorism in the world of React before the transition away from class components over to functional components and hooks
• Domain specificity in code is a red flag
• Use generics whenever you can