tab = everyone can set it to how many space you are comfortable with

just don’t use ; if you can

human don’t read semicolon if machine also don’t need it so what does it for?

if there are possibility for unexpected behavior, it may be worth to put it for safety but consider before if that is from bad writing format or from the language itself

const groupOfLogic = () => {
  a
  a

  b
  b
}


otherBlock()

can provider better outline for seperation of code

when function have many arguments it should expand to multiple line but let’s the human decide how it should be written

new line can provide a grouping of arguments

const processEntityWithPosition = (
  entity, entityRelated,
  vectorX, vectorY, vectorZ,
  other
) => {}

when you want to call or construct something with multiple lines allow to put first or any number of arguments on same line

there are many cases that it will easier to read

// seperate data from logics
pipe(data,
  fn1,
  fn2
)

the longer the variable/function/class live the longer (descriptive) the name should be

// itemValidator.js
const filterItemOnlyInStock = (items) =>
  items.filter((item) => {
    stocks = Stock.getAllStocks(item)
    return stocks.filter((s) => s.quantity > 0)
  })

additional 1 key right after you finish a line or maintaining the only last line to be without comma

treat acronym same as single word, no matter what it is any character long in this way, the rule will be simple and the same in every case style

example word: HTML, IO

in camel case: html io htmlIo ioHtml

in pascal case: Html Io HtmlIo IoHtml

in snake case: html io html_io io_html

infix

obj
  .something()
  .another()

prefix

pipe(obj,
  X.something(),
  Y.another()
)

easier to tap between pipeline by transforming function

pipe(obj,
  debug(log.info)(X.something),
  Y.another()
)

and you can still chain functions even they are not in the same class

big chunk

const buildProduct = (params) => ({
  name: params.name,
  isActive: params.isActive || true,
  price: params.price || 0,
  brand: params.brandId
    ? BrandRepo.find(params.brandId)
    : null
})

chained

const buildProduct = (name) => ({
  name,
  isActive: true,
  price: 0,
})

const setActive = (isActive) => (product) => ({
  ...product, isActive
})

const setPrice = (price) => (product) => ({
  ...product, price
})

const setBrand = (brandId) => (product) => ({
  ...product,
  brand: BrandRepo.find(brandId)
})

product = pipe(buildProduct(),
  setActive(true),
  setPrice(100),
  setBrand(1)
)

don’t need to remember parameter key easier to seperate big building logic

my suggestion

find try to retrieve something but it may not found +so return type will be the thing or null

get just retrieve something and it should be exists so return type will be only the thing and may raise exception if not found

or you can use other words you want, but be consistent and explicit for example in Laravel there are find and findOrFail or in elixir you may use get and get!

only use boolean parameter as a data, never use it for beheaviour

// isActive is the boolean flag for data strucure
function setActive(isActive) {
  row.isActive = isActive
}

// isHungry is the boolean flag (maybe) read from data structure
// but use to define behavior
function eatFood(isHungry) {
  if (isHungry) {
    // eat
  } else {
    // not eat
  }
}

for readability and also understandability when calling the function

for setActive(true) you can know right away that true is mean for active

but for eatFood(true) it hard to know what true mean

create data structure to model the data try not to create one for config behavior

data strucutre for data is obvious, but data structure for behavior may look like this

type PurchaseParam {
  isIncludeTax: boolean,
  shippingFee: number | undefined,
}

function purchase(param: PurchaseParam) {
  if (param.isIncludeTax) {
  }

  if (param.shippingFee) {
  }
}

const param = {
  isIncludeTax: // some specific 'Shop'
  shippingFee: // total price of 'Item[]' over something
}

purchase(param)

making this kind of structure is a sign that you separate the decision logic and execution logic in different place

obviously the PurchaseParam isn’t represent any kind of data or model but just used do define the behavior of this specific purchase() function

you can see from example that the actual data is Shop and Item[] and it better to just use the actual data

function purchase(shop: Shop, items: Item[]) {
  if (shop) { // specific Shop
    // include tax
  }

  if (items) { // total price over something
    // add shipping fee
  }
}

for language like js, you can use index file to be root file of directly so that you can write import with that directory name

- module
  - index.js
  - something.js
  - else.js

// when use
import 'module'

but you can do this instead

- module.js
- module
  - something.js
  - else.js

// when use
import 'module'

because with this you can start with just

- module.js

and when the module grow larger you don’t need any renaming and just create the directory with sub module

- module.js
- module
  - something.js
  - else.js

if the test fail, that means it actually is executed

I have an article for this here

when defining route, don’t define prefix in subpath

// base.js
router.use(subRoute)

// subRoute.js
router.prefix('/sub')
router.get('/', controller.get)

instead define it in base path

// base.js
router.use('/sub', subRoute)

// subRoute.js
router.get('/', controller.get)

when you digging a code of some api it’s easier to start from top level which is base path by defining prefix in base you can see which file you need to go next without jumping to that file firsts

and if you start from sub route, you can still guess prefix from file/module name