Là lập trình viên, chắc hẳn ai cũng hiểu khi khiến sach day lap trinh c việc với bất kì một ngôn ngữ, 1 framework, hay 1 thư viện nào đấy chúng ta đều được nói nhở về các “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 chiếc code “không được đẹp” một tí thì kết quả sau đó chương trình vẫn chạy đúng, trừ một đôi trường hợp ko nghe lời các bậc cao nhân mà cứ cắm mặt làm “bad practices” đẫn tới vận 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 đa dạng lúc còn dẫn đến việc thất thoát tiền tài, tốn thời kì để tu bổ,… Đáng sợ chưa.

tại sao phải viết code thật đẹp?
những vấn đề, cũng như hệ quả của việc viết code “không được đẹp” thường nằm trong giai đoạn vững mạnh ứng dụng, ví dụ như debugging hay sửa đổi tính năng,… Trong môi trường làm cho việc thực tế, cho dù áp dụng của Anh chị em sở hữu chạy tốt cỡ nào, thì vẫn sở hữu những khả năng người khác (co-worker) mò vào đọc code, hoặc thậm chí là thay đổi code của bạn ví như với nhu cầu, tỉ dụ như họ muốn viết chức năng mới dựa trên chiếc cũ, họ phải fix một con bug liên quan đến code của bạn, hay đơn giản là họ muốn đọc để hiểu hệ thống hoạt động như thế nào. Và dĩ nhiên điều tôi đề cập không loại trừ 1 ai, kể cả Anh chị cũng vẫn phải làm các điều như vậy.

toàn cầu này sẽ tươi đẹp hơn nhiều giả dụ hồ hết 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ị em viết code một lần, nhưng Cả nhà khóa học lập trình game cho trẻ em phải theo những mẫu code ấy cả “một đời”, vì thế việc thậ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 yếu. Phổ biến lúc mới code xong hôm qua, hôm nay đã bỏ quên mấy chiếc logic phức tạp bên trong nó rồi chứ chưa đề cập tới chuyện 5, 10 năm sau mò vào coi lại.

1 trong những thứ giúp ích được cho chúng ta đó chính là code comment.
Chắc hẳn phổ thông bạn đang câu hỏi, thế kỉ bao nhiêu rồi mà còn code comment, giờ là thời đại của “self documented” code rồi. Ừ thì ko ai phủ nhận việc viết code “self documented”, mà lại Anh chị đang bị lầm tưởng về chuyện tác dụng của comment trong code. Trị giá của code comment không nằm ở chỗ kể đoạn code này mang tác dụng gì, làm chiếc gì, giá trị của code comment nằm ở chỗ giảng giải vì sao đoạn code này phải viết như vậy. Và việc “self documented” chỉ có thể giúp được phần “chỗ này khiến cho gì” hay “cái này có tác dụng gì” thôi.

Comment thấp là comment giải thích được tại sao mọi thứ được làm tương tự, chứ không hề nói chỗ này khiến cho gì, sở hữu tác dụng gì, tự bản thân code đã nhắc lên được điều đấy rồi.

Quay lại sở hữu chuyện “self documented” code, để mà khiến được chuyện này, Anh chị em phải luôn nhớ trong đầu về quy tắc đặt tên (naming convention). Sách dạy tương đối phổ thông thứ rồi, thí dụ như những lệ luật viết hoa viết thường, gạch dưới, etc… Điều quan trọng mà tôi muốn đề cập ấy là, Anh chị em hãy luôn nhớ trong đầu về nguyên tắc “single responsibility”, chỉ cần Anh chị hiểu điều này, cuộc sống sẽ phát triển thành tiện lợi hơn gần như.

một dòng tên thấp là cái tên mà lúc đọc lên nó đựng chứa phần lớn thông báo về công dụng cũng như cách thức sử dụng và điều này chỉ mang thể khiến 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 đó, 1 trong các điều tôi rất hay gặp trong giai đoạn khiến việc đấy là mọi người thường nhắm mắt nhắm mũi làm ngơ việc sử dụng magic number trong code. Đây quả thật là tội ác, trong khi lúc Quan sát những phép so sánh hay các phép gán, chẳng người nào với thể hiểu được ý nghĩa của những Báo cáo ấy, tại sao lại phải là nó mà chẳng phải là một số khác. Cũng ko người nào sở hữu thể ngừa được các “tác dụng phụ” với thể xảy ra ví như lỡ tay đổi thay nó. Bởi thế hãy giảm thiểu sử dụng magic number, mà thay vào ấy là đem hết chúng vào trong file constant, rồi đặt một chiếc tên “thật hay” hoặc thậm chí là thêm vài cá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 phổ biến lắm.

1 thứ khác, dù rất nhỏ nhưng lại mang trị giá khôn cùng to để khiến code đẹp đẽ hơn đó chính là indentation, hay chúng ta thường gọi thân yêu là “thò ra thụt vô”. Dòng gì cũng vậy, để mà được xác nhận là đẹp thường phải đi với 1 kết cấu tốt (nếu Anh chị hiểu), code cũng vậy. Tỉ dụ mà block code bắt đầu “thò ra” 1 kiểu, khi kết lại “thụt vô” một kiểu khác thì ai đọc mà không khó chịu đúng không.

bên cạnh đó 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ở thành đẹp đẽ hơn. Viết code cho đẹp là cả 1 thời kỳ và để tóm lại thì chúng ta mang một số ý sau.

Code đẹp là code sở hữu kết cấu tốt, đượ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 đề cập là “spaghetti code” ấy.
Code đẹp là code phải được test tất cả, rẻ hơn hết là nên có tỉ dụ về bí quyết tiêu dùng.
Code đẹp không đồng nghĩa với code “khôn”, bạn nghĩ code bạn “khôn”, nhưng ko straight forward, người đọc ko hiểu thì cũng với ý 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à tiện dụng để tái sử dụng.
Thế nhé, hãy code thật đẹp để toàn cầu này trở thành “tươi đẹp hơn”, cảm ơn Cả nhà đã dành thời kì để đọc và hứa hẹn gặp lại Cả nhà trong những bài viết tiếp theo.