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.

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

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

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

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

About Author

BÌNH LUẬN

chuyên mục

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

Related Stories

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

287 Stories To Learn About Blockchain Development

240 Stories To Learn About Astounding Stories

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

287 Stories To Learn About Blockchain Development

240 Stories To Learn About Astounding Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps