Mùi mã là một cổ điển. Nó có mùi vì có thể có nhiều trường hợp nó có thể được chỉnh sửa hoặc cải thiện. Hầu hết những mùi này chỉ là gợi ý về điều gì đó có thể không ổn. Do đó, bản thân chúng không bắt buộc phải sửa… (Tuy nhiên, bạn nên xem xét nó.) Mã Trước Mùi Bạn có thể tìm thấy tất cả các mùi mã trước đó (Phần i - XXIX) tại đây Tiếp tục đi... Mã Mùi 146 - Getter Comments Nhận xét là một mã Mùi. Getters là một mùi mã khác. Đoán xem? TL; DR: Không sử dụng getters. Không nhận xét getters Các vấn đề Người lạm dụng bình luận khả năng đọc Getters Các giải pháp Xóa nhận xét getter Loại bỏ getters Định nghĩa bài văn Một vài thập kỷ trước, chúng tôi đã từng bình luận về mọi phương pháp. Ngay cả những thứ tầm thường. Nhận xét chỉ nên mô tả một quyết định thiết kế quan trọng. Mã mẫu Sai pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } } Đúng pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } } phát hiện Bán tự động [x] Chúng tôi có thể phát hiện xem một phương thức có phải là phương thức thu thập hay không và có nhận xét hay không. ngoại lệ Chức năng cần một nhận xét, đó vô tình là một getter và nhận xét có liên quan đến một quyết định thiết kế Thẻ Bình luận Phần kết luận Đừng bình luận getters. Họ không thêm giá trị thực và phình to mã của bạn. quan hệ Mã Mùi 05 - Kẻ Lạm Dụng Bình Luận Mật Mã Mùi 68 - Getters Mã Mùi 01 - Người Mẫu Thiếu Máu Tín dụng Ảnh của Reimond de Zuñiga trên Bapt Mã phải có tính biểu cảm rõ ràng để tránh hầu hết các nhận xét. Sẽ có một vài trường hợp ngoại lệ, nhưng chúng ta nên coi các nhận xét là 'không diễn đạt được' cho đến khi được chứng minh là sai. Robert Martin Báo giá tuyệt vời về kỹ thuật phần mềm Mã Mùi 147 - Quá Nhiều Phương Pháp Các lớp sử dụng là tuyệt vời để thu thập giao thức. TL; DR: Đừng thêm giao thức ngẫu nhiên vào lớp học của bạn Các vấn đề khả năng đọc Vi phạm trách nhiệm duy nhất Sự gắn kết kém khớp nối cao Khả năng tái sử dụng thấp Các giải pháp Phá vỡ lớp học của bạn Trích xuất lớp tái cấu trúc Tái cấu trúc 007 - Trích xuất lớp Định nghĩa bài văn Chúng tôi có xu hướng đặt một giao thức trong lớp đầu tiên mà chúng tôi tìm thấy. Đó không phải là một vấn đề. Chúng ta chỉ cần cấu trúc lại. Mã mẫu Sai public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } } Đúng public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } } phát hiện Tự động [x] Hầu hết các phương pháp linters đếm và cảnh báo chúng tôi. quan hệ Mã Mùi 124 - Thay Đổi Khác Biệt Mã Mùi 143 - Dữ Cục Mã Mùi 94 - Nhập Quá Nhiều Mã Mùi 22 - Người Giúp Việc Mã Mùi 34 - Quá Nhiều Thuộc Tính Thêm thông tin Chuyên gia tái cấu trúc Thẻ Sự gắn kết đầy hơi Phần kết luận Tách các lớp và giao thức là một cách thực hành tốt để ưu tiên các đối tượng nhỏ và có thể tái sử dụng. Tín dụng Ảnh của trên Marcin Simonides Bapt Không có mã nào quá lớn, xoắn hoặc phức tạp đến mức việc bảo trì không thể làm cho nó trở nên tồi tệ hơn. Gerald M. Weinberg Mã Mùi 148 - Việc Làm Chúng ta mua nợ cho chính chúng ta trong tương lai. Đó là thời gian hoàn vốn. TL; DR: Đừng để TODO trong mã của bạn. Sửa chúng! Các vấn đề Nợ kỹ thuật khả năng đọc Thiếu tự tin Các giải pháp Sửa TODO của bạn Định nghĩa bài văn Chúng tôi gặp TODO trong mã của chúng tôi. Chúng tôi đếm chúng. Chúng tôi hiếm khi giải quyết nó. Chúng tôi bắt đầu mắc nợ kỹ thuật. Sau đó, chúng tôi trả nợ + lãi. Vài tháng sau, chúng tôi trả lãi nhiều hơn nợ gốc. Mã mẫu Sai public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } } Đúng public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } } phát hiện Tự động [x] Chúng ta có thể đếm TODO. Thẻ Nợ kỹ thuật Phần kết luận Chúng ta có thể đếm TODO. Hầu hết các linters làm điều đó. Chúng ta cần chính sách để giảm thiểu chúng. Nếu chúng tôi đang sử dụng TDD, chúng tôi sẽ viết mã bị thiếu ngay lập tức. Trong bối cảnh này, TODO chỉ hợp lệ khi thực hiện phát triển Depth First để ghi nhớ các đường dẫn mở để truy cập. Thêm thông tin Bạn có nên đặt ToDos? Lý thuyết Windows bị hỏng Tín dụng Ảnh của trên Eden Constantino Bapt Sau khi bạn hoàn thành 90% đầu tiên của dự án, bạn phải hoàn thành 90% còn lại. Micheal Abrash Mã Mùi 149 - Tùy Ý Xích Mã của chúng tôi mạnh mẽ và dễ đọc hơn. Nhưng chúng tôi giấu NULL dưới tấm thảm. TL; DR: Tránh Nulls và không xác định. Nếu bạn tránh chúng, bạn sẽ không bao giờ cần Tùy chọn. Các vấn đề Null NẾU gây ô nhiễm Các giải pháp Xóa null Đối phó với không xác định Định nghĩa bài văn tùy chọn , Tùy chọn, Hợp nhất và nhiều giải pháp khác giúp chúng tôi xử lý các giá trị rỗng khét tiếng. Chuỗi Không cần sử dụng chúng khi mã của chúng tôi đã hoàn thiện, mạnh mẽ và không có giá trị rỗng. Mã mẫu Sai const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined Đúng function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell phát hiện Tự động [x] Đây là một . Tính năng Ngôn ngữ Chúng tôi có thể phát hiện nó và loại bỏ nó. Thẻ Vô giá trị Phần kết luận Nhiều nhà phát triển cảm thấy an toàn khi làm ô nhiễm mã với xử lý null. Trên thực tế, điều này an toàn hơn là không xử lý NULL. , Truthy và Falsy cũng là mùi mã. Nullish Values Chúng ta cần nhắm mục tiêu cao hơn và làm cho mã sạch hơn. : xóa tất cả các giá trị rỗng khỏi mã của bạn. Điều tốt : sử dụng chuỗi tùy chọn. Nhược điểm : hoàn toàn không xử lý null. Điều xấu xí quan hệ Mã Mùi 145 - Hack Đoản Mạch Mã Mùi 12 - Null Code Smell 69 - Big Bang (JavaScript Ridiculous Castings) Thêm thông tin Tham khảo chuỗi tùy chọn Null: Sai lầm hàng tỷ đô la Làm thế nào để thoát khỏi IF khó chịu mãi mãi CÁI GÌ? Tín dụng Ảnh của trên engin akyurt Bapt Anh ta chiến đấu với quái vật có thể cẩn thận kẻo anh ta trở thành một con quái vật. Và nếu bạn nhìn lâu vào một vực thẳm, thì vực thẳm cũng nhìn chằm chằm vào bạn. Nietzsche Mã Mùi 150 - So Sánh ngang tài ngang sức Mọi nhà phát triển đều so sánh các thuộc tính như nhau. Họ đã nhầm. TL;DR: Không export rồi so sánh, chỉ so sánh thôi. Các vấn đề phá vỡ đóng gói Sao chép mã Vi phạm che giấu thông tin vi phạm nhân hóa Các giải pháp Ẩn so sánh trong một phương pháp duy nhất Định nghĩa bài văn So sánh thuộc tính được sử dụng nhiều trong mã của chúng tôi. Chúng ta cần tập trung vào hành vi và trách nhiệm. Trách nhiệm của một đối tượng là so sánh với các đối tượng khác. Không phải của riêng chúng tôi. Trình tối ưu hóa sớm sẽ cho chúng tôi biết điều này kém hiệu quả hơn. Chúng ta nên yêu cầu họ cung cấp bằng chứng xác thực và đối chiếu giải pháp dễ duy trì hơn. Mã mẫu Sai if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive Đúng if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. } phát hiện Bán tự động [x] Chúng ta có thể phát hiện các so sánh thuộc tính bằng cách sử dụng cây cú pháp. Có thể có những cách sử dụng tốt cho các loại nguyên thủy cũng như với nhiều mùi khác. thẻ đóng gói Phần kết luận Chúng ta cần đặt trách nhiệm ở một nơi duy nhất. So sánh là một trong số đó. Nếu một số quy tắc kinh doanh của chúng tôi thay đổi, chúng tôi cần thay đổi một . điểm duy nhất quan hệ Mã Mùi 63 - Tính Đố Kỵ Mã mùi 101 - So sánh với Booleans Mã Mùi 122 - Ám Ảnh Nguyên Thủy Tín dụng Ảnh của trên Piret Ilver Bapt Hành vi là điều quan trọng nhất về phần mềm. Đó là những gì người dùng phụ thuộc vào. Người dùng thích khi chúng tôi thêm hành vi (miễn là đó là điều họ thực sự muốn), nhưng nếu chúng tôi thay đổi hoặc xóa hành vi mà họ phụ thuộc vào (giới thiệu lỗi), họ sẽ ngừng tin tưởng chúng tôi. michael lông vũ Bài tiếp theo: 5 mùi code nữa.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

Cách tìm các phần hôi thối trong mã của bạn [Phần XXX]

dài quá đọc không nổi

Maximiliano Contieri

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Cách tìm các phần hôi thối trong mã của bạn [Phần XXX]

dài quá đọc không nổi

Maximiliano Contieri

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN