1. Log level and semantic methods
π Console docs
console.log("hello world")
console.warn("this is a warning")
console.error("this is an error")
console.info("this is info")
console.debug("this is debug")
console.trace("show trace")
π If you try the console.warn
, you will get the trace which means that it is easier to debug the code
Let's try other console functions yourself :)
β οΈ Original code
console.log("Error: API key should not be empty")
π Refactor
console.error("Error: API key should not be empty")
2. Avoid negative names for boolean variables
π It is hard to read double negatives
isStarted π€ π€ isNotStarted
β οΈ Original code
const isInvalidApiKey = apiKey === null
if (isInvalidApiKey) {}
π Refactor
const isValidApiKey = apiKey != null
if (!isValidApiKey) {}
3. Avoid flag params
π You don't know what the flag params are used for util you have to read the function declaration
β οΈ Original code
renderResult(true)
function renderResult(isAuthenticated) {
if (isAuthenticated) {
return <p>App</p>
} else {
return <p>Please login</p>
}
}
π¨ Use object params
renderResult({isAuthenticated: true})
function renderResult({isAuthenticated}) {
if (isAuthenticated) {
return <p>App</p>
} else {
return <p>Please login</p>
}
}
π¨ Use 2 functions
function renderAuthenticatedApp() {
return <p>App</p>
}
function renderUnAuthenticatedApp() {
return <p>Please login</p>
}
isAuthenticated ? renderAuthenticatedApp() : renderUnAuthenticatedApp()
4. Use guard clauses
π Nesting hell
π¨ Make our code fail fast
π¨ Natural flow
if (statusCode === 200) {
// success
} else {
if (statusCode === 500) {
// Internal Server Error
} else if (statusCode === 400) {
// Not Found
} else {
// Other error
}
}
if (statusCode === 500) {
// Internal Server Error
}
if (statusCode === 400) {
// Not Found
}
if (statusCode !== 200) {
// Other error
}
// success
5. Make code self-explanatory
π¨ Easy to understand
π¨ Reusable
π¨ A long descriptive name is better than a long comment
// verify that user has added a credit card
function verify(user) {}
function verifyThatUserHasAddedCreditCard(user) {}
β οΈ Original code
if (country !== 'finland' &&
country !== 'germany' &&
country !== 'vietnam' &&
country !== 'russia' &&
type !== 'π£'
) {
return Promise.reject('Not available')
}
π Refactor
const isInAvailableCountries = (
country === 'finland' ||
country === 'germany' ||
country === 'vietnam' ||
country === 'russia'
)
const hasBoom = type === 'π£'
if (!isInAvailableCountries || hasBoom) {
return Promise.reject('Not available')
}
π Create a better condition
const availableCountries = ['finland', 'germany', 'vietnam', 'russia']
const isInAvailableCountries = availableCountries.includes(country)
const hasBoom = type === 'π£'
if (!isInAvailableCountries || hasBoom) {
return Promise.reject('Not available')
}
6. Make impossible states impossible
π¨ Easy to understand
π¨ Prevent lots of bugs
π Stop using isLoading booleans
isLoading: true
isError: false
isLoading: false
isError: true
// imposible states
isLoading: true
isError: true
const LOADING_STATE = 'LOADING_STATE'
const ERROR_STATE = 'ERROR_STATE'
const state = LOADING_STATE
β οΈ Original code
const [isLoading, setIsLoading] = React.useState(false)
const [error, setError] = React.useState(null)
const [coffee, setCoffee] = React.useState(null)
function handleButtonClick() {
setIsLoading(true)
setError(null)
setCoffee(null)
getCoffee('cappuccino', 'small', 'finland', true).then(coffee => {
setIsLoading(false)
setError(null)
setCoffee(coffee)
}).catch(error => {
setIsLoading(false)
setError(error)
})
}
π Refactor
const state = {
idle: 'idle',
loading: 'loading',
error: 'error',
success: 'success',
}
const [error, setError] = React.useState(null)
const [coffee, setCoffee] = React.useState(null)
const [status, setStatus] = React.useState(state.idle)
function handleButtonClick() {
setStatus(state.loading)
getCoffee('cappuccino', 'small', 'finland', true).then(coffee => {
setStatus(state.success)
setCoffee(coffee)
}).catch(error => {
setStatus(state.error)
setError(error)
})
}
7. Use objects for long argument lists
π¨ Params order won't matter
π¨ Easy to pass optional param
function getBox(type, size, price, color) {}
getBox('carry', undefined, 10, 'red')
function getBox(options) {
const {type, size, price, color} = options
}
getBox({
type: 'carry',
price: 10,
color: 'red'
})
β οΈ Original code
export function getCoffee(type, size, country, hasIce) {
getCoffee('cappuccino', 'small', 'finland', true)
}
π Refactor
function getCoffee(options) {
const {type, size, country, hasIce} = options
}
getCoffee({
type: 'cappuccino',
size: 'small',
country: 'finland',
hasIce: true
})
8. Use Object.assign for defaults
function getBox(options) {
options.type = options.type || 'carry'
options.size = options.size || 'small'
options.price = options.price || 10
options.color = options.color || 'red'
const {type, size, price, color} = options
}
function getBox(customOptions) {
const defaults = {
type: 'carry',
size: 'small',
price: 10,
color: 'red',
}
const options = Object.assign(defaults, customOptions)
const {type, size, price, color} = options
}
β οΈ Original code
export function getCoffee(type, size, country, hasIce) {
type = type || 'cappuccino'
size = size || 'small'
country = country || 'finland'
hasIce = hasIce || false
}
π Refactor
function getCoffee(customOptions) {
const defaultOptions = {
type: 'cappuccino',
size: 'small',
country: 'finland',
hasIce: false
}
const options = Object.assign(defaultOptions, customOptions)
}
function getCoffee(options = {}) {
const {
type = 'cappuccino',
size = 'small',
country = 'finland',
hasIce = false
} = options
}
function getCoffee({
type = 'cappuccino',
size = 'small',
country = 'finland',
hasIce = false
} = {}) {
}
9. Replacing switch statements with Object literals
Honestly, I love switch as well and I don't actually know when to use switch statement vs object literals. My feeling just tells me which one to go.
Check out these 2 blogs and decide which one is better for you
π Replacing switch statements with Object literals
π Switch is ok
const handleSaveCalculation = ({key}) => {
switch (key) {
case 'save-copy': {
saveCopy()
break
}
case 'override': {
override()
break
}
default:
throw Error('Unknown action')
}
}
handleSaveCalculation({key: 'save-copy'})
const handleSaveCalculation = ({key}) => {
const actions = {
'save-copy': saveCopy,
'override': override,
'default': () => throw Error('Unknown action')
}
const action = key in actions ? actions[key] : actions['default']
return action();
}
handleSaveCalculation({key: 'save-copy'})
β οΈ Original code
let drink
switch(type) {
case 'cappuccino':
drink = 'Cappuccino';
break;
case 'flatWhite':
drink = 'Flat White';
break;
case 'espresso':
drink = 'Espresso';
break;
default:
drink = 'Unknown drink';
}
π Refactor
const menu = {
'cappuccino': 'Cappuccino',
'flatWhite': 'Flat White',
'espresso': 'Espresso',
'default': 'Unknown drink'
}
const drink = menu[type] || menu['default']
10. Avoid Hasty Abstractions
π I don't know how to create a good abstraction but I've created many bad ones
π¨ prefer duplication over the wrong abstraction
π¨ Nothing is free. The code trades the ability to change requirements for reduced duplication, and it is not a good trade - Dan Abramov
π AHA Programming
π Goodbye, Clean Code
β οΈ My React Boilerplate
The code below is used to fetch an order and I am using Redux for the state management. What a boilerplate!!! Let's make an abstraction which I will regret later
Fetch an order
// Action Type
const FETCH_ORDERS_START = "FETCH_ORDERS_START";
const FETCH_ORDERS_SUCCESS = "FETCH_ORDERS_SUCCESS";
const FETCH_ORDERS_FAILED = "FETCH_ORDERS_FAILED";
// Action
export const fetchOrder = (token) => {
return dispatch => {
dispatch(fetchOrdersStart);
axios.get('/orders.json?auth=' + token).then(res => {
dispatch(fetchOrdersSuccess(res));
}).catch(err => {
dispatch(fetchOrdersFailed(err));
});
};
}
export const fetchOrdersSuccess = (orders) => {
return {
type: FETCH_ORDERS_SUCCESS,
orders: orders,
};
};
export const fetchOrdersFailed = (error) => {
return {
type: FETCH_ORDERS_FAILED,
error: error,
};
};
export const fetchOrdersStart = () => {
return {
type: FETCH_ORDERS_START,
};
};
ποΈ Abstraction
I dare you understand the abstraction code without clicking the link. And even go to that link, you have to read all the code to understand that abstraction.
If you want to take a deep look into this, checkout AHA Programming and Goodbye, Clean Code
// Action
const moduleName = 'order'
const path = '/order'
const {moduleActionTypes, moduleActions} = useModuleActions(moduleName, path)
function fetchOrder() {
moduleActionTypes.getModel()
}
function updateOrder(data) {
moduleActionTypes.updateModel(data)
}
Top comments (7)
Appreciated this post. I will only add that I personally hate
if/else
statements when thereturn
could make them obsolete. In practice, this means that I would convert this:To this:
And if I'm being really nitpicky, I would personally write it as this:
And if I'm really feeling concise, I'd write it as this:
@bytebodger The simple
if-else
usually don't needelse
so I personally would stick toif + return
(first refactor) when the if or else blocks have a few lines. The second and third only if the cases are simple π.@dinhhuyams nice summary :)
Points are mostly valid, outside of this one with switch. Switch is ok
Thanks for sharing. To be honest, I love to use switch a lot. Sometimes I prefer Object literals :) I don't know when it is better to use Switch or Object literals. My feeling just tells me which one to go. I added your blog to the Switch section.
11.TypeScript π
This is awesome. Thanks for sharing.
nice