-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code style preferences and guidelines #82
Comments
We define MapTrack in export type MapTrack = (nft: NFT, apiTrack: any, nftFactory?: NftFactory | undefined, trackId?: string) => ProcessedTrack; But then we also re-specify the types when implementing it. e.g. const mapTrack: MapTrack = (
nft: NFT,
apiTrack: any,
contract?: NftFactory,
trackId?: string,
): ProcessedTrack => { // ... What do we think about cleaning things up a bit and leaning on the TS types instead? const mapTrack: MapTrack = (
nft,
apiTrack,
contract?,
trackId?,
) => { // ... An example of what this cleanup looks is here: e0f4be1 |
ye sounds great |
the linked changes look good too |
When creating a function where the context for its parameters is self evident, prefer short names instead of being overly specific. Style recommendation based on discussion in https://github.com/spinamp/spindexer/pull/76/files#r965095193 |
We don't make use of TODOs in the codebase, prefer github issues or just tackle the problem if it isn't a major change! Source: |
While we extend and cleanup some areas of the codebase, we should start to discuss some of our coding style preferences to prepare for some kind of
contributions.md
file in future.This issue can be a place for us to discuss our preferences.
Ongoing List of Standards:
Function signatures
General
TODOs
in the codebase. Rather generate a Github issue with a decent description.The text was updated successfully, but these errors were encountered: