Bài viết này tôi sẽ đưa ra 10 quy tắc được rút ra trong quá trình làm việc và tìm hiểu. Đừng chỉ đọc, hãy mở editor lên và code thử nhé

Trước hết, chuẩn bị nội dung sau 🍽️

Để những quy tắc nêu ra trong bài viết này thêm trực quan, tôi đã chuẩn bị 1 ví dụ sau:

  • Cho phép user nhập thông tin
  • Khi nhấn submit, nội dung sẽ được kiểm duyệt
  • Nếu thông tin hợp lệ, hiển thị preview và thêm vào list of users

Tiếp theo, thì hãy thử áp dụng các quy tắc dưới đây vào ví dụ trên

1/ Sử dụng let, const thay cho var 🌍

Bộ 3 từ khóa trên đều được sử dụng để khai báo giá trị cho biến. Tuy nhiên, chúng có những khác biệt cơ bản như sau

  • var - đưa toàn bộ khai báo lên đầu scope, thường gây ra hiện tượng hoisting variable
  • let - khai báo biến ngay tại vị trí scope
  • const - khai báo hằng số, giá trị được khai báo không thể thay đổi

Do nhược điểm của var ở trên nên hầu hết các ứng dụng web hiện tại không chấp nhận việc sử dụng nó nữa

Nên việc đầu tiên là chuyển toàn bộ var sang sử dụng let hoặc const

2/ Khai báo biến ở vị trí trên cùng thay vì tràn lan trong code🗼

Đoạn code của chúng ta có 1 số biến được định nghĩa mỗi khi <form/> submit. Việc này là không cần thiết

3/ Sử dụng object destructing 🗽

Khi cần truy xuất trường dữ liệu trong 1 object, thay vì tạo 1 biến mới và gán giá trị của object vào đối tượng đó thì có thể sử dụng cú pháp sau

const userInfo = {name: 'John doe', age: 24}
const { name } = userInfo

Áp dụng vào source code ta được kết quả sau

4/ Hạn chế sử dụng if lồng nhau😖

Câu lệnh điều kiện càng đơn giản, thì code càng dễ hiểu. Thay vì viết lồng nhiều if làm tăng độ phức tạp, thì chúng ta nên đơn giản hóa điều kiện

Hãy sử dụng các câu lệnh điều kiện dạng ngắt. Kiểu như: nếu không thỏa mã, bỏ qua.

Giở thử thay đổi điều kiện "nếu độ dài tên nhỏ hơn 30 và tuổi lớn hơn 0" trong ví dụ

5/ Gộp nhiều đoạn code thành 1 function 🗝️

Độ dài của 1 xử lý ảnh hưởng rất nhiều đến quá trình đọc hiểu, fixbug và cải thiện chất lượng source code

Code ngắn thường dễ đọc hiểu và ngược lại. Nên là, nếu dài quá thì gộp lại thành function

Ví dụ trên có các đoạn code về kiểm duyệt dữ liệu, hiển thị preview và thêm mới thông tin có thể gộp thành 3 function: isValidData, previewData, addNewInfo

6/ Sử dụng Template strings 🗳️

Quy tắc này không bắt buộc, bạn có thể thực hiện hoặc không. Chẳng qua, viết teamplate strings sẽ KHÔNG CẦN PHẢI:

  • dùng dấu + để nối chuỗi
  • bổ sung kí tự escape khi viết: 'I\'m John'

7/ Sử dụng asyncawait kết hợp lambda function 🖐️

Bất đồng bộ thường gây ra 1 vấn đề được gọi là callback hell, đại khái có thể hiểu là việc sử dụng quá nhiều callback. Việc này thường xảy ra khi chúng ta có nhiều xử lý cần phải đợi kết quả từ xử lý trước mới có thể thực hiện được

Để giải quyết vấn đề này thì asyncawait ra đời. Quay lại ví dụ của chúng ta, hãy áp dụng vào hàm saveToDatabase. Nhớ là

  • await luôn luôn phải nằm trong async
  • async không cần thiết phải có await
  • async chỉ được sử dụng với function

8/ Thay đổi thứ tự thực thi code ♻️

Thông thường, với tôi, việc đọc code luôn bắt đầu từ trên xuống dưới, và phải có 1 điểm bắt đầu

Do đó, để dễ đọc hiểu hơn, tôi thường chuyển thứ tự thực thi code theo chiều từ trên xuống dưới

Trên cùng là nơi toàn bộ xử lý được bắt đầu, các xử lý phụ thì sắp đặt bên dưới. Trong ví dụ của chúng ta, tôi sẽ chuyển sự kiện submit của <form /> lên đầu tiên, thay vì dưới cùng

9/ Đừng lặp lại những công việc mà bạn thấy phiền ⚠️

Nếu chỉ đọc bài viết này, thì có lẽ các bạn sẽ ko cảm nhận được. Nhưng nếu mà thử thực hiện, các bạn sẽ thấy rằng việc viết đi viết lại câu lệnh document.get..., document.query... rất là mệt mỏi. Nhất là khi đã mỏi tay rồi mà bàn phím còn kẹt nút 😡😡

Do đó, nếu có thể viết ngắn hơn, thì đừng đắn đo nhiều, sửa luôn cho đỡ mỏi

10/ Sử dụng comment để làm rõ chức năng thực hiện 💬

Có nhiều quan điểm về việc sử dụng comment trong code. Tiêu biểu có thể kể đến 2 quan điểm:

  • Code phải có nhiều comment mới tốt
  • Code ít comment mà vẫn hiểu được mới là tốt

Thực tế 2 quan điểm này không hề sai, tuy nhiên, lời khuyên cho các bạn newbie là nên comment để hiểu mình đã và đang làm gì

Hơn nữa, lập trình không phải là 1 công việc cá nhân, mà có tính đồng đội rất cao. Do đó, việc mô tả công việc của mình cho đồng đội hiểu là rất quan trọng

Kết

Trên đây chắc chắn không phải là những quy tắc hoàn chỉnh và đầy đủ nhất. Nó chỉ là những kinh nghiệm mà tôi đúc kết, tìm hiểu và chia sẻ cho các bạn.

Hy vọng qua đó các bạn có thể tự nắn chỉnh bản thân để cải thiện hơn nữa chất lượng code của mình

Nếu thấy hữu ích hãy chia sẻ cho bạn bè của bạn, cùng làm và cùng thay đổi.