TypeScript styleguide

[sverps]

I propose choosing and following a style guide to get more consistency throughout the code.

My choice would be to follow google's style guide.

Some possible exceptions:

• To avoid having to rename practically all files, I think we could opt to disregard the filename rule.
• [anything else?]

[carletex]

Thanks for this @sverps !

I think being consistent is the key here.

The google guide is huge and we shouldn't try to follow it word by word. Just use it as a reference / starting point and stick to what works for us. We can also use it when we don't have a strong opinion about something, to help us decide.

• I like this for Identifiers:

• Rename all the Types that start with T?

• I like type inference https://google.github.io/styleguide/tsguide.html#type-inference

• Interface vs Types. They chose interfaces: https://google.github.io/styleguide/tsguide.html#interfaces-vs-type-aliases. We chose Types (except IUtilityButton in utilsDisplay :D) The difference is minimal => key is to be consistent. We can change it if you'all feel like it.

For JSDocs comments

• Remove @dev (inherited from Solidity, not valid JSdocs. Talked with Shiv about this)

• love this also :D
  

• They use single quotes (even if they don't mention it, they just use them in their example). Let's stick with double quotes :D

• I prefer using "~/whatever", than "../.../whatever"
  

---

Left a few notes and... actionable items?

And lets keep discussing! Thanks.

[rin-st]

To avoid having to rename practically all files, I think we could opt to disregard the filename rule.

Yep, let's leave it as is:
UpperCamelCase for components/solidity contracts and tests for them
kebab-case for pages
snake_case ? for hardhat/deploy files
lowerCamelCase for everything else

---

Agree with everything @carletex wrote.

Interface vs Types

I prefer to use Types

Rename all the Types that start with T?

Yes, except types in generics, as @sverps wrote here #231 (comment)

---

Again, regarding default export

Next.js supports lazy loading for named exports using next/dynamic docs.

So, if you're ok with writing one additional then for potential lazy loading, we probably don't need default exports anymore

[ByteAtATime]

My personal opinion, I think we can leave default exports as-is, since it's very common in React.