30 ngày jav
Mình thấy bài viết hay quá nên đọc và viết lại, chủ yếu để mình và các bạn viết code có nguyên tắc, dễ đọc, dễ hiểu, dễ bảo trì và code tái sử dụng hơn, mình có tham khảo tại Show
https. //github. com/hienvd/clean-code-javascript/ https. //github. com/ryanmcdermott/clean-code-javascript Giới thiệuCác nguyên tắc kỹ thuật phần mềm, từ cuốn sách Clean Code của Robert C. Martin's, được áp dụng cho ngôn ngữ JavaScript. Đây không phải là một hướng dẫn về cách viết mã Javascript mà là hướng dẫn về cách viết các đoạn mã dễ đọc, tái sử dụng và tái cấu trúc được trong Javascript Không phải mọi nguyên tắc nghiêm trọng ở đây đều phải được tuân thủ một cách nghiêm ngặt, và thậm chí chỉ có một số ít trong số đó được sử dụng phổ biến. Ở đây, nó chỉ là một hướng dẫn - không hơn không kém, nhưng chúng là hệ thống hóa thông tin qua kinh nghiệm được thu thập qua nhiều năm của các tác giả của cuốn sách Clean Code Ngành kỹ thuật phần mềm chỉ phát triển đã hơn 50 năm, và chúng ta vẫn đang học rất nhiều. Một khi kiến trúc phần mềm trở nên phổ biến, có thể sau đó chúng ta sẽ có thêm nhiều luật lệ khó hơn phải tuân theo. Còn lại đây, hãy đi theo những hướng dẫn này như một tiêu chuẩn để đánh giá chất lượng các đoạn mã Javascript mà bạn và nhóm của bạn tạo ra. Biết những hướng dẫn này thôi sẽ không thể ngay lập tức khiến bạn trở thành một lập trình viên phần mềm tốt hơn được, và làm việc với họ trong nhiều năm cũng không có nghĩa là bạn sẽ không gặp bất kỳ sai lầm nào. Mỗi đoạn mã bắt đầu như một bản thảo đầu tiên, giống như đất sét được làm môi và cho đến cuối cùng thì nó sẽ lộ ra một hình hài. Cuối cùng, chúng ta gọt tỉa những điểm còn thiếu khi chúng ta xem xét lại nó cùng với các đồng nghiệp. Đừng để bản thân bạn bị đánh bại bởi những thảo luận đầu tiên, thứ mà vẫn cần phải được chỉnh sửa. Thay vào đó hãy đánh bại những dòng mã Áp dụngVariationSử dụng tên biến có nghĩa
Sử dụng cùng từ vựng cho cùng một loại biến
Sử dụng các tên dễ hiểu và tìm kiếm đượcChúng ta sẽ đọc mã nhiều hơn là viết chúng. Điều quan trọng là mã chúng tôi viết có thể đọc được và tìm kiếm được. Việc đặt tên các biến không có nghĩa vì vậy với chương trình, chúng ta có thể sẽ khiến người đọc mã bị tổn thương tinh thần. Hãy làm cho tên biến của bạn có thể tìm kiếm được. Các công cụ như bạn thân. js và ESLint có thể giúp nhận ra các hằng số chưa được đặt tên
Theo mình thì nên có 1 thư mục ( directory ) để định nghĩa các hằng số dùng chung này Sử dụng các biến có thể giải thích được
Bảo vệ không gây hại cho người khácTrước giờ, không riêng gì trong lập trình mà mọi vấn đề vẫn tồn tại trong cuộc sống, nếu rõ ràng thì tất nhiên nó vẫn sẽ dễ hiểu hơn
Don't add the contexts not essentialNếu tên của lớp ( lớp ), tên của đối tượng đã nói lên điều gì đó, ít nhất nó là cái gì thì không cần phải lặp lại nó trong tên biến ( biến )
0
1Sử dụng các tham số mặc định còn hơn là kiểm tra
2
3Giăm bôngĐối số của hàm (lý tưởng là ít hơn hoặc bằng 2)Tham số number ( tham số ) truyền vào 1 hàm là điều cực kỳ quan trọng. Nó làm cho bạn ít nhất cũng dễ nhìn hơn, dễ test hơn, Trong trường hợp có nhiều hơn 3 thông số có thể khiến bạn phải test hàng tấn test case khác nhau với những đối số riêng biệt 1 hoặc 2 tham số là lý tưởng cho 1 hàm, nhưng có trường hợp bất khả kháng thì cũng đành chấp nhận, tốt nhất là nên tránh truyền nhiều hơn 2 tham số, những trường hợp từ 3 tham số, chúng ta nên hạn lại Thông thường thì công việc truyền càng nhiều tham số cho hàm, hàm đó sẽ càng xử lý nhiều công việc hơn Kể từ khi Javascript cho phép tạo nhiều Object một cách nhanh chóng, mà không cần nhiều class có sẵn, bạn có thể sử dụng một Object mà bạn cần truyền nhiều tham số To wait for clear a function mong muốn thuộc tính gì, bạn có thể sử dụng cấu trúc phá hủy cấu trúc của ES6. Điều này có một số điểm ưu tiên
4
5Hàm chỉ nên giải quyết một vấn đềĐây là quy định quan trọng nhất của kỹ thuật phần mềm. Khi một hàm thực hiện nhiều hơn 1 công việc, chúng sẽ trở nên khó khăn hơn để viết code, test và suy luận Khi bạn có thể tách biệt một hàm để chỉ thực hiện một hành động, thì sẽ dễ dàng hơn để tái tạo cấu trúc và mã của bạn sẽ dễ đọc hơn nhiều. Nếu bạn chỉ cần làm theo hướng dẫn này thôi mà không cần làm gì khác thì bạn cũng đã giỏi hơn nhiều nhà phát triển khác rồi
6
7Tên chức năng phải nói ra được những gì họ làmNhìn vào tên hàm thôi mà chính bạn hay người khác cũng hiểu mục đích của hàm đó làm gì
8
9Hàm chỉ nên có một lớp vật liệuKhi có nhiều hơn một lớp phụ, chức năng của bạn đang làm quá nhiều. Chia nhỏ các hàm ra sẽ làm cho công việc kiểm tra và tái sử dụng dễ dàng hơn
0
1Dimiting codeViệc có hai hàm xử lý cùng một chức năng như nhau thì là việc phải tránh, đó là mã trùng lặp. code trùng lặp thì không tốt bởi vì nếu bạn cần thay đổi cùng một logic, bạn phải sửa ở nhiều nơi hơn Hãy tưởng tượng nếu bạn điều hành một nhà hàng và bạn theo dõi hàng tồn tại. bao gồm cà chua, hành tây, tỏi, gia vị, vv. Nếu bạn có nhiều danh sách quản lý, thì tất cả chúng phải được thay đổi khi bạn phục vụ một món ăn có chứa cà chua. Nếu bạn chỉ có 1 danh sách, thì việc cập nhật ở một nơi thôi Thông thường, bạn có những dòng mã lặp lại bởi vì bạn có 2 hay nhiều hơn những thứ chỉ khác nhau một chút, mà chia sẻ nhiều thứ chung, nhưng sự khác nhau của chúng buộc bạn phải có 2 hay nhiều hàm riêng biệt để . Xóa đi những dòng mã trùng lặp có nghĩa là tạo ra một trừu tượng có thể xử lý các tập tin điểm khác biệt này chỉ với một hàm/mô-đun hoặc lớp Có một sự trừu tượng đúng thì rất quan trọng, đó là lý do tại sao bạn nên chấp hành các nguyên tắc RẮN được đặt ra trong phần lớp. Những trừu tượng không tốt có thể còn tệ hơn cả những dòng mã bị lặp, vì thế hãy cẩn thận. Nếu bạn có thể tạo ra một sự trừu tượng tốt, hãy làm nó. Đừng quay lại chính mình, nếu bạn không muốn đi cập nhật nhiều nơi bất cứ khi nào bạn muốn thay đổi một thứ gì đó
2
3Thiết lập các đối tượng mặc định với Object. giao phó
4
5Don't use the flags as a number of functionCác biến cờ cho người dùng của bạn biết rằng chức năng thực hiện nhiều hơn một công việc. function only should doing a task. Vì vậy hãy tách hàm của bạn nếu chúng đang làm cho mã phụ dựa trên một biến boolean
6
7Don't use the flags as a number of functionMột chức năng tạo ảnh hưởng phụ nếu nó làm bất kỳ điều gì khác hơn là nhận một giá trị ban đầu và trả về một hoặc nhiều giá trị. Ảnh hưởng phụ có thể là ghi một tệp, thay đổi một vài biến toàn cục hoặc vô tình bạn đã trả tất cả tiền cho một người lạ Bây giờ, cũng có khi bạn cần ảnh hưởng phụ trong một chương trình. Giống như ví dụ trước, bạn cần ghi một tập tin. Những gì bạn cần làm là tập trung vào nơi bạn sẽ làm nó. Don't viết hàm và lớp riêng biệt để tạo ra một tệp cụ thể. Hãy có một dịch vụ để viết nó. One and only one Điểm chính là để tránh những lỗi chung như chia sẻ trạng thái giữa các đối tượng mà không có cấu trúc bất kỳ, việc sử dụng các kiểu dữ liệu có thể thay đổi được mà có thể được viết bởi bất cứ thứ gì và không . Nếu bạn có thể làm được điều đó, bạn sẽ cảm thấy hạnh phúc hơn với phần lớn các lập trình viên khác đấy
8
9Tránh những ảnh hưởng phụ (phần 2)Trong JavaScript, các kiểu cơ bản được truyền theo giá trị và các đối tượng/mảng được truyền theo tham chiếu. Trong trường hợp các đối tượng và mảng, ví dụ: nếu hàm của chúng ta tạo ra thay đổi trong một mảng giỏ mua hàng, ví dụ: thêm một sản phẩm để mua, thì bất kỳ hàm nào khác mà sử dụng mảng 'giỏ hàng' sẽ . Điều này có thể tốt, tuy nhiên nó cũng có thể trở nên tồi tệ. Vui lòng tưởng tượng trường hợp xấu sau Người sử dụng nhấp chuột "Mua hàng", nút mua hàng sẽ gọi tới hàm mua, cái mà sinh ra một yêu cầu mạng và gửi giỏ lên máy chủ. Do nối kết chậm, chức năng mua có thể tiếp tục thử lại yêu cầu. Bây giờ, nếu trong thời gian đó người sử dụng vô tình nhấn chuột vào nút "Thêm vào giỏ hàng" ở một sản phẩm mà họ không thực sự muốn trước khi mạng thực hiện yêu cầu? Một giải pháp tốt là chức năng thêm sản phẩm vào giỏ hàng luôn luôn tạo ra một sao của giỏ, thay đổi nó và trả về bản sao đó. Điều này chắc chắn không có chức năng nào có phụ kiện giữ tham chiếu của giỏ mua hàng bị ảnh hưởng bởi bất kỳ sự thay đổi nào Hai lưu ý cho cách tiếp cận này
0
1Don't write up the global functionsViệc lướt ảnh ảnh hưởng đến các biến toàn cục là một cách làm không tốt trong JavaScript vì bạn có thể xung đột với các thư viện khác và người dùng API của bạn sẽ không biết trước khi xảy ra sự cố trên sản phẩm. Hãy suy nghĩ ví dụ này. Điều gì xảy ra nếu bạn muốn mở rộng phương thức của Array trong JavaScript gốc để có thể có một hàm 84 chỉ khác nhau giữa hai mảng? . Điều gì xảy ra nếu thư viện đó chỉ sử dụng 84 để tìm sự khác biệt giữa phần tử đầu tiên và phần cuối cùng của một mảng?
2
3Ủng hộ lập trình chức năng hơn là lập mệnh lệnhJavaScript không phải là ngôn ngữ lập trình hàm giống như Haskell, nhưng nó có chức năng đặc trưng của nó. Những ngôn ngữ lập trình hàm thì gọn gàng và dễ kiểm tra hơn. Vui lòng sử dụng cách thiết lập chương trình này khi bạn có thể
4
5Đóng gói các điều kiện
6
7Điều kiện hủy bỏ tiêu cực
8
9Điều kiện thoátThis way as a job any time. Khi nghe điều này đầu tiên, hầu hết mọi người đều nói, "Làm sao tôi phải làm gì mà không có mệnh đề nếu?" Câu hỏi thứ hai thường là "Đó là điều tốt nhưng tại sao tôi lại muốn làm điều đó?" . one function only should done a job. Khi bạn có nhiều lớp và hàm mà có nhiều mệnh đề 87, bạn đang cho người dùng của mình biết rằng hàm của bạn đang làm nhiều hơn một công việc. Hãy nhớ, chỉ làm một công việc thôi
0
1Checkout type (phần 1)JavaScript không định dạng, có nghĩa là hàm của bạn có thể nhận bất kỳ đối số kiểu nào. Đôi khi bạn được cám dỗ bởi sự tự do này và dễ dàng dẫn đến công việc kiểm tra kiểu trong chức năng của mình. Có nhiều cách để tránh phải làm điều này. Điều đầu tiên là xem xét sử dụng các API quán nhất
2
3Check type check (phần 2)Nếu bạn đang làm việc với các kiểu cơ bản như chuỗi, số nguyên và mảng, và bạn không thể sử dụng đa hình nhưng bạn vẫn cảm thấy cần phải kiểm tra kiểu, bạn nên xem xét việc sử dụng TypeScript. Nó là một phương pháp thay thế tuyệt vời cho JavaScript thông thường, bởi vì nó cung cấp kiểu tĩnh bên ngoài cú pháp JavaScript chuẩn. Vấn đề liên quan đến việc kiểm tra kiểu thủ công là để làm tốt công việc này yêu cầu nhiều dòng dài mà "kiểu an toàn" giả mạo này không thay thế được cho việc mất tính dễ đọc của mã. Hãy giữ mã JavaScript của bạn sạch sẽ, viết bài kiểm tra tốt và có mã đánh giá tốt. Nếu không thì thực hiện tất cả những điều đó nhưng với TypeScript (giống như tôi đã nói, đó là sự thay thế tốt. )
4
5Don't too minimumCác trình duyệt hiện đại làm rất nhiều tối ưu hóa bên dưới trong thời gian chạy. Rất nhiều lần, nếu bạn là người tối ưu, thì bạn đang làm thời gian của chính mình. Xem ở đây để biết khi nào công việc tối ưu hóa bị thiếu. Hãy thực hiện những điều tối thiểu đó và cho đến khi chúng được chỉnh sửa nếu có thể
6
7Xóa mã chết (mã chết)Mã chết tệ cũng như mã trùng lặp. Không có lý do gì để giữ chúng lại trong codebase của bạn. Nếu nó không được gọi nữa, hãy bỏ nó đi. Nó vẫn sẽ nằm trong lịch sử phiên bản của bạn nếu bạn vẫn cần nó
8
9Object and Constructor dataUse getter and setterJavaScript không có 88 hoặc kiểu vì rất khó để thực hiện mô hình này, bởi vì chúng ta không có các từ khóa như 89 và 90. Vì vậy, sử dụng 91 và 92 để truy cập dữ liệu trên các đối tượng thì tốt hơn là chỉ đơn giản là tìm kiếm một thuộc tính trên một đối tượng. Bạn có thể hỏi "Tại sao?"This is a list of lí do at sao
0
1Làm cho các đối tượng có thành viên riêng tưĐiều này có thể được thực hiện thông qua các lần đóng (đối với ES5 và cũ hơn)
0
3ClassƯu tiên lớp ES2015/ES6 hơn các chức năng thuần ES5Rất khó để có thể đọc được lớp kế thừa, lớp khởi tạo và định nghĩa phương thức trong các lớp ES5 cổ điển. Nếu bạn cần kế thừa (và lưu ý rằng bạn không thể), tốt hơn hết là nên sử dụng Lớp. Tuy nhiên, ưu tiên sử dụng những hàm nhỏ hơn là lớp cho đến khi bạn cần những đối tượng lớn và phức tạp hơn
4
5Sử dụng các hàm liên tiếpĐây là một mẫu rất hữu ích trong JavaScript và bạn đã thấy nó trong rất nhiều thư viện chẳng hạn như jQuery và Lodash Nó cho phép mã của bạn có tính năng tải xuống và rút gọn. Vì lý do đó, theo tôi, hãy sử dụng phương pháp các hàm liên tiếp và hãy xem mã của bạn sẽ sạch sẽ như thế nào. Trong các hàm của lớp, đơn giản là trả về 97 ở cuối mỗi hàm, và bạn có thể xâu chuỗi các phương thức khác nhau vào trong nó
6
7Ưu tiên thành phần hơn là kế thừaNhư đã được nhấn mạnh nhiều trong Design Patterns của Gang of Four, bạn nên sử dụng cấu trúc thành phần hơn là kế thừa nếu có thể. Có rất nhiều lý do tốt để sử dụng kế thừa cũng như sử dụng thành phần. Điểm nhấn cho phương pháp châm cứu này là nếu tâm trí của bạn đi theo khả năng thừa kế, hãy thử nghĩ xem liệu các thành phần có thể mô phỏng vấn đề của bạn tốt hơn hay không. In a number of field it could Bạn có thể tự hỏi, "khi nào tôi nên sử dụng thừa kế?"
8
9CHẤT RẮNNguyên lý đơn trách nhiệm (Single Responsibility Principle)Như đã được đề cập trong cuốn sách Clean Code, "Chỉ có thể thay đổi một lớp vì lý do duy nhất". Thật là một đường dẫn hấp dẫn để ghép nhiều chức năng vào một lớp, giống như khi bạn chỉ có thể lấy một chiếc vali cho chuyến bay vậy. Vấn đề là lớp của bạn sẽ không hiểu được kết nối về mặt khái niệm của nó và sẽ có rất nhiều lý do để thay đổi. Việc làm giảm thiểu số lần bạn cần phải thay đổi một lớp là một công việc quan trọng. Nó quan trọng bởi vì nếu có quá nhiều chức năng trong một lớp và bạn chỉ muốn thay đổi một chút của lớp đó, thì có thể sẽ rất khó để hiểu được việc thay đổi đó sẽ ảnh hưởng đến những mô-đun khác trong cơ sở mã của bạn
0
1Nguyên lý đóng mở (Open/Closed Principle)Bertrand Meyer đã nói "có thể thoải mái mở rộng một mô-đun, nhưng hạn chế sửa đổi bên trong mô-đun đó". Điều đó nghĩa là gì?
2
3Nguyên lí thay thế Liskov (Nguyên tắc thay thế Liskov)Đây là một thuật ngữ đáng sợ cho một khái niệm rất đơn giản. Nó được định nghĩa một cách chính thức là. "If S is a type of T, then the objects of the type T could be instead by the objects of the type S (ví dụ các đối tượng của kiểu S có thể thay thế các đối tượng của kiểu T) that . ). That even chí but is a định nghĩa đáng sợ hơn Sự thật tốt nhất cho nguyên lí này là, nếu bạn có một lớp cha và một lớp con, thì lớp cơ sở và lớp con có thể được sử dụng thay thế cho nhau mà không làm thay đổi tính đúng đắn của chương trình. Có thể vẫn còn hơi rối ở đây, vì vậy hãy xem ví dụ cổ điển hình vuông-hình chữ nhật (Square-Rectangle) dưới đây. Về mặt toán học, một hình vuông là một hình chữ nhật, tuy nhiên nếu bạn mô hình hóa điều này sử dụng quan hệ "là" thông qua công việc kế thừa, bạn sẽ nhanh chóng gặp phải rắc rối đó.
4
5Nguyên lý phân tách giao diện (Nguyên tắc phân tách giao diện)JavaScript không có giao diện vì vậy nguyên lí này không áp dụng một cách chặt chẽ như các nguyên lí khác. Tuy nhiên, nó cũng quan trọng và liên quan ngay cả với hệ thống thiếu định dạng của JavaScript Nguyên lý phân tách giao diện nhấn mạnh rằng "Người dùng không nên bị bắt buộc phải phụ thuộc vào các giao diện mà họ không sử dụng. " Giao diện là bắt buộc phải ẩn trong JavaScript bởi vì duck typing Một ví dụ tốt để minh hoạ cho nguyên lí này trong JavaScript là các lớp yêu cầu cài đặt các đối tượng lớn. Việc không yêu cầu người dùng thiết lập một số lượng lớn các tùy chọn tùy chỉnh là một lợi ích, bởi vì đa số thời gian họ không cần tất cả các cài đặt. Làm cho chúng trở thành lựa chọn tùy ý giúp tránh được việc có một "giao diện béo"
6
7Nguyên tắc đảo ngược phụ thuộc (Nguyên tắc đảo ngược phụ thuộc)Nguyên lý này khẳng định hai điều kiện cần thiết sau
Điều này có thể khó hiểu khi ban đầu, nhưng nếu bạn đã từng làm việc với Angular. js, bạn đã thấy sự thực thi của nguyên lí này dưới dạng của Dependency Injection (DI). Khi chúng không phải là các khái niệm giống nhau, DIP giữ cho mô-đun cấp cao không biết chi tiết các mô-đun cấp thấp của nó và thiết lập của chúng. You can get this thing through DI. Một lợi ích lớn của DIP là nó làm giảm sự phụ thuộc lẫn nhau giữa các mô-đun. Sự phụ thuộc lẫn nhau là một kiểu mẫu không tốt, vì nó làm cho việc tái cấu trúc mã trở nên khó khăn Như đã khẳng định ở trước, JavaScript không có giao diện vì vậy các trừu tượng mà bị phụ thuộc là các ràng buộc ẩn. Đó là để nói, các phương thức và thuộc tính mà một đối tượng/lớp làm hiển thị đối tượng/lớp khác. Trong ví dụ bên dưới, ràng buộc ẩn là bất kỳ mô-đun nào Request for a InventoryRequester will have a requestItems method
8
9thử nghiệmTesting thì quan trọng hơn shipping. Nếu bạn không kiểm tra hoặc không đủ, thì mỗi lần ship code bạn sẽ không chắc mình có làm hư hại gì không. Việc quyết định những gì để tạo ra số lượng kiểm tra đủ là do nhóm của bạn, nhưng việc có 100% mức độ bao phủ (tất cả các câu lệnh và rẽ nhánh) là cách để bạn đạt được sự tự tin cao. Điều này có nghĩa là bên ngoài công việc có khuôn khổ để kiểm tra điều tốt, bạn cũng cần sử dụng một công cụ bao trùm điều tốt Không có lý do gì để không viết bài kiểm tra. Có rất nhiều điều tốt, vì vậy hãy thử tìm một khuôn khổ mà nhóm bạn thích. Khi đã tìm được một cái thích hợp với đội của mình, hãy đặt tiêu đề để luôn luôn viết bài kiểm tra cho từng tính năng hoặc mô-đun mới của bạn. Nếu phương pháp thử nghiệm ưa thích của bạn là Test Driven Development (TDD), thì điều đó thật tuyệt vời, nhưng điểm quan trọng là bạn phải đảm bảo rằng bạn đạt được mục tiêu về mức độ phủ trước khi khởi chạy một tính năng hoặc cấu trúc lại một tính năng cũ Một khái niệm duy nhất cho mỗi bài kiểm tra đơn vị
0
1Xử lý đồng thờiPlease use Promise, don't use callbackCallback thì không được 'sạch sẽ' cho lắm, chúng gây ra quá nhiều đoạn code lồng nhau (callback hell). Từ ES2015/ES6, Promise đã được đưa vào Javascript. Please use them
2
3Async/Await thì 'sạch sẽ' hơn PromiseHứa hẹn là một sự thay thế 'sạch sẽ' cho gọi lại, nhưng ES2017/ES8 giới thiệu không đồng bộ và chờ đợi, thậm chí chí chí còn là một giải pháp tốt hơn Promise nữa. Những gì bạn cần phải làm là một hàm có tiếp đầu ngữ là từ khoá không đồng bộ, và bạn có thể viết các logic lệnh mà không cần một chuỗi sau đó của các hàm. Hãy sử dụng điều này nếu bạn có thể tận dụng các tính năng của ES2017/ES8 ngay hôm nay
3
5Xử lý lỗiDon't bỏ qua những lỗi đã bắt đượcNếu không làm gì với lỗi đã bắt được, bạn sẽ không thể sửa hoặc phản hồi lại lỗi đã bắt được. Ghi lỗi ra 98 (bảng điều khiển. log) cũng không tốt hơn bao nhiêu vì đa số nó có thể bị trôi mất trong một ngăn xếp thứ được hiển thị ra ở bảng điều khiển. Nếu bạn đặt bất kỳ đoạn mã nào trong một khối thử/bắt, tức là bạn nghĩ rằng một lỗi có thể xảy ra ở đây, thì bạn có nên có một giải pháp hoặc tạo một mã luồng để xử lý lỗi khi nó xảy ra không
6
7Don't bỏ qua những lời hứa bị lỗi (bị từ chối)With the integer kernel with on
8
9formatViewing code format mang tính chủ quan. Giống như nhiều quy tắc được trình bày trong tài liệu này, không có quy tắc nào khó nhắc và nhanh chóng mà bạn bắt buộc phải tuân theo. Điểm chính của phần này là KHÔNG BẢO GIỜ TRANH CÀI về việc định dạng mã như thế nào. Có hàng tá công cụ để tự động hóa công việc này. Hãy sử dụng bất kỳ công cụ nào. Thật thời gian và tiền bạc chỉ để tranh cãi về vấn đề định dạng mã Đối chiếu với những thứ không thuộc phạm vi của mã định dạng tự động của công việc (thụt đầu dòng, tab và dấu cách, nháy đơn và nháy kép,. ) hãy xem một số hướng dẫn ở đây Sử dụng hệ thống cách viết hoa tốt nhấtJavascript là một ngôn ngữ không định kiểu, vì vậy việc viết hoa sẽ nói lên rất nhiều về các biến, hàm,. của bạn. Những quy tắc này thì mang tính chủ quan, vì thế đội bạn có thể chọn quy tắc nào họ muốn. Tuy nhiên, điều quan trọng là cho dù bạn chọn cách viết như thế nào, thì hãy sử dụng hệ thống tốt nhất trong codebase của bạn
0
1Các hàm gọi và hàm được gọi nên nằm gần nhauNếu một hàm gọi một hàm khác, hãy giữ các hàm này gần theo chiều dọc trong tệp. Lí tưởng là, hãy giữ cho hàm gọi ở trên hàm được gọi. Chúng ta có xu hướng đọc mã từ trên xuống, giống như đọc báo vậy. Do đó, hãy làm cho mã của chúng ta cũng được đọc theo cách đó
2
3Viết chú thíchChỉ nên viết chú thích cho những thứ có logic phức tạpCác chú thích thông thường là lời xin lỗi, chứ không phải là yêu cầu. Những đoạn code tốt thì multi number nó đã là tài liệu rồi
4
5Đừng giữ lại những đoạn mã được chú thích trong cơ sở mã của bạnNhững công cụ quản lý phiên bản sinh ra để thực hiện nhiệm vụ của họ. Please to your old code is back in tiền đi
6
7Đừng viết nhật ký chú thíchHãy nhớ, sử dụng công cụ quản lý phiên bản. Chúng ta không cần những đoạn mã vô dụng, chú thích và đặc biệt là những chú thích định dạng nhật ký. Sử dụng 99 để xem lịch sử được mà
8
9Undefault the positionChúng thường xuyên làm nhiễu mã. Hãy để các tên hàm, biến tương tự với các định dạng thích hợp tự tạo thành cấu trúc trực quan cho mã của bạn |