Nói lời tạm biệt với các thực hành javascript xấu

Nov 29 2022

Khi chúng ta bước những bước đầu tiên vào thế giới lập trình tuyệt vời, chúng ta sẽ tự mình chứng kiến những gì nó mang lại cho hàng triệu người. Nhờ lập trình mà cuộc sống của rất nhiều người trở nên dễ dàng hơn, chỉ bằng cách nhấn một vài phím trên thiết bị của họ (Điều này thật kỳ diệu).

Lập trình là một loại siêu năng lực khác, nhưng như chú Ben đã nói với cháu trai của mình, Peter Parker, "Sức mạnh lớn đi kèm với trách nhiệm lớn." Trong thế giới lập trình, trách nhiệm lớn nhất của chúng ta là đảm bảo rằng mã chúng ta viết vừa dễ kiểm tra vừa có thể duy trì được theo thời gian.

Có một số thực tiễn nhỏ trong lập trình có thể liên tục tác động tiêu cực đến mã chúng ta viết và sản phẩm cuối cùng chúng ta tạo ra. Tôi đã trực tiếp trải nghiệm những vấn đề này. Điều quan trọng là phải chia sẻ chúng là gì và tại sao bạn nên tránh chúng bằng mọi giá.

1. Sử dụng var thay cho let và const

Đã đến lúc nói lời tạm biệt với việc sử dụng var.

Bạn chỉ nên sử dụng let và const vì những lý do sau:

● Phạm vi rõ ràng hơn (giữa các mắc cài).

● Nó không tạo các đối tượng toàn cầu.

● Nó báo lỗi nếu bạn khai báo lại chúng.

Trừ khi bạn đang sử dụng một trình duyệt cũ hơn chẳng hạn như IE11 được yêu thích, nếu không thì tốt nhất bạn nên bỏ qua var. Let và const sẽ là những người bạn tốt nhất của bạn trong tương lai.

2. Sử dụng comment để giải thích code

Nhận xét là một phần cơ bản khi chúng tôi xây dựng phần mềm, chúng giúp chúng tôi hiểu rõ hơn một chút mã mà chúng tôi đang đọc, nhưng chúng tôi không được mắc lỗi khi giải thích từng bước mã của chúng tôi làm gì, chúng tôi phải tạo mã dễ hiểu đọc và nhận xét chỉ nên cung cấp ngữ cảnh.

Dưới đây là một số mẹo và lời nhắc để giúp bạn viết nhận xét mã như một chuyên gia:

● Tránh dư thừa trong nhận xét của bạn; đừng viết những gì bạn làm, hãy viết tại sao bạn làm điều đó.

● Tên biến/chức năng/lớp mô tả tốt hơn so với nhận xét mô tả.

● Tóm tắt càng nhiều càng tốt; không viết thành đoạn nếu không thật cần thiết.

● Cố gắng luôn sử dụng cùng một ngôn ngữ và phong cách bình luận.

● Theo thời gian, ý kiến thường không được duy trì (sửa đổi) mã được.

3. Sử dụng == thay vì ===

Điều đầu tiên cần hiểu là mặc dù nhìn bề ngoài chúng rất giống nhau, nhưng chúng làm những việc khác nhau: toán tử thứ nhất được gọi là toán tử đẳng thức chính quy (==) và toán tử thứ hai được gọi là toán tử đẳng thức nghiêm ngặt (===).

Toán tử đẳng thức thông thường (==) chỉ kiểm tra xem các toán hạng có giống nhau hay không, điều này có thể gây ra một số bất ngờ khó chịu.

Toán tử đẳng thức nghiêm ngặt (===) luôn kiểm tra xem các toán hạng có kiểu và giá trị khác nhau không và chúng có hoàn toàn giống nhau không.

4. Quên sử dụng chuỗi tùy chọn

Toán tử tạo chuỗi tùy chọn (?), cho phép bạn đọc giá trị của một thuộc tính nằm sâu trong chuỗi các đối tượng được kết nối mà không cần phải kiểm tra mọi tham chiếu đơn lẻ trong chuỗi.

Điều này giúp chúng tôi tránh lỗi khi cố gắng truy cập một thuộc tính không tồn tại. Ví dụ: giả sử chúng ta có một đối tượng Pokémon chứa thông tin của Pokémon đó.

Khi chúng tôi muốn truy cập một thuộc tính không được xác định, chẳng hạn như trong ví dụ này, việc truy cập Javascript 'tấn công' thuộc tính sẽ tạo ra lỗi và ứng dụng của chúng tôi sẽ bị hỏng. Khi sử dụng chuỗi tùy chọn (?), Javascript sẽ cho chúng tôi biết rằng thuộc tính không được xác định nhưng sẽ không tạo ra bất kỳ lỗi nào. Suy nghĩ về những loại lỗi đôi khi nằm ngoài tầm kiểm soát của chúng ta sẽ tạo ra sự khác biệt lớn về lâu dài.

5. Không sử dụng chuỗi ma thuật và số ma thuật

Số ma thuật hoặc chuỗi ma thuật là các số hoặc chuỗi được sử dụng trực tiếp trong mã thường không có ngữ cảnh rõ ràng nhưng có mục đích. Tốt nhất là gán các giá trị này cho các hằng số, vì chúng có thể trở nên khó hiểu và khó gỡ lỗi.

6. Xử lý lỗi lệnh gọi API không đúng cách

Chúng ta phải luôn xử lý lỗi bằng try/catch trong async/await.

Nếu chúng tôi không xử lý những sai sót trong lời hứa của mình thì rất có thể ứng dụng của chúng tôi sẽ bùng nổ, và tin tôi đi, chúng tôi không muốn điều đó xảy ra đâu.

7. Sử dụng một đối tượng như một tham số duy nhất

Khi khai báo một hàm có nhiều giá trị được mong đợi từ một đối tượng, cách tốt nhất là sử dụng nhiều tham số đầu vào thay vì đầu vào một đối tượng. Điều này giúp chúng tôi với một số điều:

Đầu tiên, nó làm cho mã của chúng ta dễ đọc hơn bằng cách biết ngay từ đầu những tham số mà hàm của chúng ta cần.

Thứ hai, nó làm cho chức năng dễ kiểm tra hơn và hai điều này cùng nhau giúp sản phẩm của chúng tôi có thể bảo trì được theo thời gian. Ngoài ra, như một điểm cộng, nó cải thiện hiệu suất của ứng dụng của chúng tôi vì nó tránh thu gom rác hoặc tạo các tham số đối tượng không cần thiết.

Một điểm cộng nữa là nếu bạn sử dụng TypeScript và bạn có một số tham số, thì việc xác định giao diện của các tham số sẽ dễ dàng hơn để hưởng lợi từ việc kiểm tra kiểu và đề xuất tự động giúp chúng ta tránh được lỗi.

8. Quên sức mạnh của chữ viết tắt

Tất cả chúng ta đều đã từng tự hỏi liệu một biến có tồn tại hay không hoặc liệu nó có chứa một loại giá trị nào đó không phải là null hoặc không xác định hay không. Vì điều này, cuối cùng chúng tôi thường thực hiện các xác nhận siêu dài thuộc loại này:

Chữ viết tắt giúp chúng ta tránh vấn đề này. Theo một cách đơn giản và thanh lịch hơn, đoạn mã trên có thể được rút gọn thành như sau:

Sự kết luận

Viết mã sạch sẽ luôn là trách nhiệm của chúng tôi. Theo kinh nghiệm của tôi với tư cách là một nhà phát triển, tôi đã học được rằng việc có mã dễ đọc và dễ bảo trì sẽ giúp bạn và nhóm của bạn tiết kiệm được nhiều giờ.

Hãy nhớ rằng chúng ta dành nhiều thời gian để đọc mã hơn là viết nó. Tôi hy vọng những mẹo nhỏ này sẽ tạo điều kiện thuận lợi cho bạn trong việc tạo ra những sản phẩm kỳ diệu và tuyệt vời.

Nếu bạn có bất kỳ đề xuất nào, vui lòng chia sẻ chúng trong phần bình luận. Cùng nhau, chúng ta có thể tiếp tục phát triển.