Coding Best Practices

Code guidelines

Prefer small, simpler functions and components over longer ones. Bigger functions and components can always be decomposed into smaller parts.

Why?

Bigger Functions/components are harder to follow/read. They can also introduce complexities into your type declarations and testing.

Ideally, Functions should hardly be longer than 20 lines. When it starts to get longer than that, start thinking of how you could break down the complexity and abstract more specific logics out into other functions, in line with Single Responsibility of the SOLID principle.

Why?

keeping things more focused can help keep others reading your code engaged.

DRY up your code, however, be mindful of premature abstractions/generalizations. It’s okay to repeat somethings. It can help to save some headaches down the line if you did not make a wide generalization earlier on. Use your discretion to strike a balance.

It is okay not to know every underlying implementation details of each sub-function just the same way we utilize helpers from third party libraries and not worry about their implementation details. We mostly care about what arguments the function takes and what it returns. Typescript and automated testing of your helper function can help to increase confidence. However, when creating abstraction, consider if people would ever have to understand the nitty-gritty of your abstraction to use it well. Otherwise, consider simplifying it

Why?

A

React Components should hardly be longer than 100 - 200 lines. Rather than having several logics in a component, abstract the logic into normal helper functions or hooks if the logic relies on other hooks.

Prefer at most 5-10 custom properties for your react component. Having more custom properties might be a sign that you need to break down the component into smaller parts and group them into a logical shared folder

Avoid passing props beyond one level. Prop drilling can often make debugging harder and also make it difficult for others to follow your code. When you need to pass props beyond one level, prefer using Context API with hooks. This combined with typescript greatly simplifies things

Be mindful of premature optimizations with React’s memoizing functionalities as React is quite fast. Memoizing introduces complexities into your codebase, hence, you want to be sure that you are reaping the benefits

Use very specific descriptive names for variables, functions, components, and types, even when it seems longer e.g getEntireStudentsSummerData over getData.

Why?

It reduces the mental work for others and yourself to understand your code. It documents your code better and prevents the need for comments oftentimes. Too much commenting of code can also be a bad practice because the code and comment could get out of sync if the implementation changes at some point but the developer forgets to change the comment.

Prefer pure functions whenever possible.

Why?

They are easier to test and lead to fewer bugs.

Prefer arrow functions whenever possible.

Why?

They are easier to type and more predictable(no this complication).

Type your react component as FunctionComponent(FC)

interface ModalProps{
  id: string
}
const Modal:FC<ModalProps> = () => {
  return (
    <div>
    Some text here
    </div>
  )
}

Avoid big reducers as they are just like every other function. Reducers can always be split into sub-reducers.The React ecosystem has moved from HOC/Props towards more functional hooks, hence, we should try to move towards that as they are simpler, easier to type and debug

Avoid reinventing the wheel.

Why?

It saves time and energy

However, avoid overusing of third-party libraries. If it will take just a few lines to implement functionality, it might be better to just implement that yourself rather than downloading an entire library?

Why?

It reduces the work of upgrading dependencies.

It helps with bundle-sizes, especially when the alternative library does not support tree-shaking.

Not having to deal with breaking changes introduced by the third-party library.

Be mindful of using third-party libraries with smaller community/support, except if it’s critical and time-saving.