yatsg is a personal style guide that I usually follow when writing TypeScript code. This generally borrows heavily from the standard.js style guide, so it may be worth checking that out first.
- Naming Convention
- Specific Data Types
- Collections
- File Naming
- Controversial Takes
- Using semicolons for line endings
- Using one-liners for short logic/objects
- Avoiding JSON
Proper nomenclature should be used, following camelCase (excluding a few edge cases). To sum it up, camelCase is:
...the practice of writing phrases without spaces or punctuation. It indicates the separation of words with a single capitalized letter, and the first word starting with either case. Common examples include "iPhone" and "eBay"... sometimes used in online usernames such as "johnSmith"...
For instance, a variable storing an API Key must be named apiKey, following camelCase standards. In rare cases though, camelCase should be disregarded, mainly for globals. Globals must be uppercase; Eg: PUBLIC_KEY or DATASTORE.
Not all variables can be named similarly using camelCase, however. Following are some primitive specific naming conventions:
- Strings/Numbers/Functions - As stated above, with a concise yet descriptive name that explains its contents precisely. Eg:
apiKey,percentFloat. - Booleans - Booleans should be named such that their type is evident from the naming. Strategies include using verbs such as "is". Eg:
isSuccessful,didFail. - BigInt - BigInts should be named in sentence case. Eg:
UserId.
As usual, camelCase must be followed; recommended to either append "data" to the name or include a plural noun. Eg: users, userData.
camelCase should usually be regarded. Specific files should have prepends in title describing their type, i.e., a shared libraries for fetching data can be named libDataStore. Directories should use common truncated names such as "src" and "lib". Avoid using "Source" or "Common" as names for the aforementioned.
Following are some specific rules I follow — do keep in mind these are heavily opinionated.
Lines must end with a semi-colon, even though the V8 engine automatically fills them out in memory. Semicolons make your code feel more "tightly-packed" and clean (plus, c'mon, they're just 1 character).
Simple and short logic (such as filter) or objects may not prettified. This keeps them short and to-the-point, rather than taking up extra space that could otherwise be occupied by more complex code.
People often use JSON for storing larger objects, which I find a bit sloppy. JSON is notorious for being sluggish, and is perhaps one of the worst choices (excluding XML) for storing large amounts of data. Either store the objects directly as variables within your code, or opt for a more efficient alternative (say, TOML).