Là lập trình viên, chắc hẳn ai cũng hiểu lúc khiến sach day lap trinh cviệc sở hữu bất kì một ngôn ngữ, 1 framework, hay một thư viện nào ấy chúng ta đều được nói nhở về những “best practices” và “bad practices” (chơi chữ đó). Và chúng ta cũng thường tự lừa dối bản thân rằng cho dù lâu lâu chúng ta vẫn buông lơi đôi tay, viết vài dòng code “không được đẹp” một tí thì kết quả sau ấy chương trình vẫn chạy đúng, trừ một đôi trường hợp ko nghe lời những bậc cao nhân mà cứ cắm mặt khiến cho “bad practices” đẫn tới áp dụng bị những trắc trở về performance hay thậm chí là crash giữa chừng, mà mấy câu chuyện này rộng rãi lúc còn dẫn đến việc thất thoát tiền của, tốn thời kì để sửa sang,… Đáng sợ chưa. vì sao phải viết code thật đẹp? các vấn đề, cũng như hệ quả của việc viết code “không được đẹp” thường nằm trong quá trình lớn mạnh áp dụng, ví dụ như debugging hay sửa đổi tính năng,… Trong môi trường khiến cho việc thực tế, cho dù vận dụng của Anh chị với chạy rẻ cỡ nào, thì vẫn mang những khả năng người khác (co-worker) mò vào đọc code, hoặc thậm chí là đổi thay code của bạn giả dụ có nhu cầu, thí dụ như họ muốn viết chức năng mới dựa trên cái cũ, họ phải fix 1 con bug can dự đến code của bạn, hay đơn thuần là họ muốn đọc để hiểu hệ thống hoạt động như thế nào. Và hẳn nhiên điều tôi nói không chiếc trừ một ai, kể cả Các bạn cũng vẫn phải làm các điều tương tự. toàn cầu này sẽ tươi đẹp hơn đa dạng nếu như gần như các loại thể code người ta viết ra đều dễ đọc và dễ hiểu. khiến sao để viết code thật đẹp? Anh chị viết code 1 lần, nhưng Các bạn khóa học lập trình game cho trẻ emphải theo các mẫu code ấy cả “một đời”, bởi thế việc cẩn trọng về cách thức đặt tên, hay document lại các thành phần phức tạp càng phát triển thành quan trọng. Phổ biến khi mới code xong hôm qua, bữa nay đã bỏ quên mấy loại logic phức tạp bên trong nó rồi chứ chưa nhắc tới chuyện 5, 10 năm sau mò vào coi lại. một trong các thứ giúp ích được cho chúng ta ấy chính là code comment. Chắc hẳn phổ thông bạn đang câu hỏi, thế kỉ bao lăm rồi mà còn code comment, giờ là thời đại của “self documented” code rồi. Ừ thì ko người nào phủ nhận việc viết code “self documented”, nhưng mà Các bạn đang bị lầm tưởng về chuyện tác dụng của comment trong code. Trị giá của code comment ko nằm ở chỗ nói đoạn code này với tác dụng gì, làm cái gì, trị giá của code comment nằm ở chỗ giảng giải vì sao đoạn code này phải viết tương tự. Và việc “self documented” chỉ mang thể giúp được phần “chỗ này làm cho gì” hay “cái này mang tác dụng gì” thôi. Comment rẻ là comment giải thích được tại sao mọi thứ được khiến cho tương tự, chứ chẳng phải nói chỗ này khiến gì, với tác dụng gì, tự bản thân code đã đề cập lên được điều đấy rồi. Quay lại với chuyện “self documented” code, để mà làm được chuyện này, Các bạn phải luôn nhớ trong đầu về luật lệ đặt tên (naming convention). Sách dạy hơi đa dạng thứ rồi, tỉ dụ như các lề luật viết hoa viết thường, gạch dưới, etc… Điều quan yếu mà tôi muốn đề cập đó là, Anh chị em hãy luôn nhớ trong đầu về nguyên tắc “single responsibility”, chỉ cần Cả nhà hiểu điều này, cuộc sống sẽ trở thành tiện lợi hơn gần như. 1 cái tên thấp là cái tên mà khi đọc lên nó cất cất phần lớn thông tin về công dụng cũng như cách thức dùng và điều này chỉ có thể làm cho được nếu tuân thủ nguyên tắc “single responsibility”. Xem thêm =>>https://mindx.edu.vn/blog/post/sach-day-lap-trinh-co-ban bên cạnh đó, một trong những điều tôi rất hay gặp trong thời kỳ làm cho việc đó là mọi người thường nhắm mắt nhắm mũi khiến cho ngơ việc dùng magic number trong code. Đây quả tình là tội ác, khi mà lúc Nhìn vào các phép so sánh hay những phép gán, chẳng ai có thể hiểu được ý nghĩa của những Con số đó, vì sao lại phải là nó mà ko phải là một số khác. Cũng ko ai mang thể đề phòng được những “tác dụng phụ” có thể xảy ra giả dụ lỡ tay đổi thay nó. Do vậy hãy giảm thiểu sử dụng magic number, mà thay vào đó là đem hết chúng vào trong file constant, rồi đặt 1 mẫu tên “thật hay” hoặc thậm chí là thêm vài loại comment giảng giải ý nghĩa, thì người khác đọc code sẽ cảm thấy “yêu” bạn hơn nhiều lắm. 1 thứ khác, dù rất nhỏ nhưng lại với trị giá khôn xiết lớn để khiến cho code đẹp đẽ hơn ấy chính là indentation, hay chúng ta thường gọi thân thương là “thò ra thụt vô”. Loại gì cũng vậy, để mà được công nhận là đẹp thường phải đi sở hữu một kết cấu tốt (nếu Anh chị hiểu), code cũng vậy. Thí dụ mà block code khởi đầu “thò ra” 1 kiểu, lúc kết lại “thụt vô” một kiểu khác thì người nào đọc mà không khó chịu đúng không. không những thế còn gì không? Và thật ra còn hàng trăm hàng ngàn thứ khác để giúp code chúng ta trở nên đẹp đẽ hơn. Viết code cho đẹp là cả 1 giai đoạn và để tóm lại thì chúng ta với một số ý sau. Code đẹp là code sở hữu kết cấu rẻ, được diễn ra phải chăng chứ không như 1 đống lộn xộn, mà giới developer thế giới hay nói là “spaghetti code” đấy. Code đẹp là code phải được test đầy đủ, thấp hơn hết là nên mang tỉ dụ về bí quyết tiêu dùng. Code đẹp ko đồng nghĩa có code “khôn”, bạn nghĩ code bạn “khôn”, nhưng không straight forward, người đọc ko hiểu thì cũng mang ý nghĩa gì đâu, code vẫn là gớm thôi. Code đẹp là code ngắn gọn, từng unit phải “nhỏ xinh” vữa đủ, và thuận tiện để tái dùng. Thế nhé, hãy code thật đẹp để thế giới này phát triển thành “tươi đẹp hơn”, cảm ơn Anh chị đã dành thời gian để đọc và hứa gặp lại Cả nhà trong các bài viết tiếp theo.
