Clean Code chương 12

CLEAN CODE A handbook of agile software craftsmanship (Code – Cẩm nang lập trình viên) Dịch Google Translate & NQT CHƯƠNG *** CODE SẠCH Bạn đọc sách hai lý Thứ nhất, bạn lập trình viên Thứ hai, bạn muốn trở thành lập trình viên giỏi Tuyệt vời! Chúng tơi cần lập trình viên giỏi Đây sách nói cách để bạn code tốt hơn, chứa đầy code Chúng ta xem xét code từ nhiều phương diện, từ xuống dưới, từ lên trên, từ Khi xong việc, biết thêm nhiều code Hơn nữa, nói khác biệt code “xịn” (good code) code “rởm” (bad code), biết cách tạo nên code “xịn”, học cách hô biến code “rởm” thành code “xịn” Sẽ (vẫn) có code Nhiều người cho việc viết code, sau vài năm khơng cịn vấn đề, nên quan tâm đến mơ hình yêu cầu Thực tế, số người cho việc viết code dần đến lúc phải kết thúc, code tạo thay viết hay gõ Và lập trình viên “gà mờ” phải tìm cơng việc khác khách hàng họ tạo nên chương trình cách nhập vào thông số cần thiết… Oh sh*t, rõ vô lý! Code không bị loại bỏ chúng đại diện cho nội dung yêu cầu khách hàng Ở mức độ đó, nội dung khơng thể bỏ qua trừu tượng hóa; chúng phải thiết lập Việc thiết lập nội dung mà máy tính hiểu thi hành, gọi lập trình, lập trình cần có code Tơi hy vọng mức độ trừu tượng ngơn ngữ lập trình số lượng DSL (DomainSpecific Language – ngôn ngữ chuyên biệt dành cho vấn đề cụ thể) tăng lên Đó dấu hiệu tốt Nhưng dù điều xãy ra, khơng “đá đít” code Các đặc điểm kỹ thuật viết ngôn ngữ bậc cao DSL code Nó cần nghiêm ngặt, xác, theo nguyên tắc, tường tận cỗ máy hiểu thực thi Những người nghĩ việc viết code đến ngày tàn giống việc nhà toán học hy vọng khám phá thể loại tốn học khơng chứa ngun tắc, định lý hay công thức Họ hy vọng ngày đó, lập trình viên tạo cỗ máy làm điều họ muốn (chứ khơng cần lệnh giọng nói) Những cỗ máy phải có khả hiểu họ tốt đến nỗi, chúng có khả dịch u cầu mơ hồ thành chương trình hồn hảo, đáp ứng xác u cầu Dĩ nhiên, chuyện xãy phim viễn tưởng Ngay người, với tất giác quan sáng tạo, thành công việc hiểu cảm xúc mơ hồ người khác Thật vậy, hỏi q trình phân tích u cầu khách hàng dạy cho điều gì, câu trả lời yêu cầu định rõ ràng, trơng giống code hoạt động trình kiểm tra Hãy nhớ điều code thực ngôn ngữ mà đó, cơng việc cuối thể u cầu Chúng tơi tạo ngôn ngữ gần với yêu cầu, tạo cơng cụ cho phép phân tích cú pháp lắp ráp chúng vào chương trình Nhưng không bỏ qua u cầu cần thiết – vậy, code ln tồn Code tồi, Code “rởm” Gần đây, có đọc phần mở đầu Implementation Patterns.1 Kent Beck Ơng nói “…cuốn sách dựa tiền đề mong manh: vấn đề code sạch…” Mong manh ư? Tôi không đồng ý chút Tơi nghĩ tiền đề tiền đề mạnh mẽ nhất, nhận ủng hộ lớn từ nhân viên (và nghĩ Kent biết điều đó) Chúng tơi biết vấn đề code chúng tơi phải đối mặt với q lâu Tơi có biết công ty, vào cuối năm 80, phát hành ứng dụng X Nó phổ biến, nhiều chuyên gia mua sử dụng Nhưng sau đó, chu kỳ cập nhật bắt đầu bị kéo dài ra, nhiều lỗi khơng sửa từ phiên qua phiên khác, thời gian tải cố theo mà tăng lên Tơi nhớ ngày mà ngưng sử dụng sản phẩm thất vọng khơng dùng lại lần Chỉ thời gian sau, công ty ngừng hoạt động Hai mươi năm sau, tơi gặp nhân viên ban đầu công ty hỏi chuyện xãy Câu trả lời khiến lo sợ : Họ đưa sản phẩm thị trường với đống code hỗn độn Khi tính thêm vào ngày nhiều, code chương trình lại ngày tệ, tệ đến mức họ khơng thể kiểm soát nữa, đặt dấu chấm hết cho cơng ty Và, tơi gọi dịng code code “rởm” Bạn bị dòng code “rởm” gây khó dễ chưa? Nếu lập trình viên hẳn bạn trải nghiệm cảm giác vài lần Chúng tơi có tên cho nó, bơi (từ gốc: wade – làm việc vất vả) Chúng tơi bơi qua dịng code tởm lợm, bơi mớ lộn xộn bug giấu kín Chúng tơi cố gắng theo cách chúng tơi, hy vọng tìm thấy gợi ý, manh mối hay biết chuyện xãy với code; tất chúng tơi thấy dịng code ngày vơ nghĩa Nếu bạn bị dịng code “rởm” cản trở tơi miêu tả, – bạn lại tạo nó? Bạn thử nhanh? Bạn vội vàng? Có lẽ thật Hoặc bạn cảm thấy bạn khơng có đủ thời gian để hồn thành nó; hay sếp điên với bạn bạn dành thời gian để dọn dẹp đống code lộn xộn Cũng có lẽ bạn mệt mỏi với chương trình muốn kết thúc Hoặc bạn xem xét phần tồn đọng thứ khác mà bạn hứa hoàn thành nhận bạn cần phải kết hợp module với để bạn chuyển sang phần Yeah! Chúng ta tạo quỷ Tất nhìn vào đống lộn xộn mà vừa tạo ra, chọn ngày đẹp trời để giải Tất cảm thấy nhẹ nhõm thấy “chương trình lộn xộn” hoạt động cho rằng: có cịn khơng Tất tự nhủ rằng, sau trở lại dọn dẹp mớ hỗ lốn Dĩ nhiên, ngày đến quy luật LeBlanc: SAU NÀY đồng nghĩa với KHÔNG BAO GIỜ! Cái giá lộn xộn Nếu bạn lập trình viên làm việc năm, bạn bị mớ code lộn xộn người khác kéo bạn lùi lại Nếu bạn lập trình viên lâu năm, bạn tự làm chậm phát triển thân đống code bạn tạo Trong khoảng năm, đội di chuyển nhanh từ bắt đầu dự án, thay phải di chuyển thận trọng cách họ nhìn nhận Vì vậy, thay đổi mà họ tác động lên code phá vỡ vài đoạn code khác Khơng có thay đổi khơng quan trọng Mọi bổ sung thay đổi chương trình tạo mớ boòng boong, nút thắt, Chúng ta cố gắng hiểu chúng để tạo thêm thay đổi, lặp lại việc tạo chúng Theo thời gian, code trở nên q “cao siêu” mà khơng thành viên hiểu Chúng ta “làm sạch” chúng, hồn tồn khơng có cách  Khi đống code lộn xộn tạo ra, hiệu suất đội bắt đầu tuột dốc phía Khi hiệu suất giảm, người quản lý làm công việc họ - đưa vào nhóm nhiều thành viên với hy vọng cải thiện tình trạng Nhưng nhân viên lại thường không nắm rõ cách hoạt động thiết kế hệ thống, họ không thay đổi phù hợp cho dự án Hơn nữa, họ người cũ nhóm phải chịu áp lực khủng khiếp cho tình trạng tồi tệ nhóm Vậy là, làm việc, họ tạo nhiều code rối, đưa nhóm (một lần nữa) dần tiến cột mốc Đập xây lại Cuối cùng, nhóm định loạn Họ thơng báo cho quản lý họ tiếp tục phát triển đống code lộn xộn nữa, họ muốn thiết kế lại dự án Dĩ nhiên ban quản lý không muốn thêm tài nguyên cho việc tái khởi động dự án, họ phủ nhận thật hiệu suất làm việc nhóm tàn tạ Cuối cùng, họ chiều theo yêu cầu lập trình viên cho phép bắt đầu lại dự án Một nhóm chọn Mọi người muốn tham gia nhóm động đầy sức sống Nhưng người giỏi chọn, người khác phải tiếp tục trì dự án Và bây giờ, hai nhóm đua Nhóm phải xây dựng hệ thống với chức hệ thống cũ, họ phải theo kịp với thay đổi dành cho hệ thống cũ Ban quản lý không thay hệ thống cũ hệ thống làm tất công việc hệ thống cũ làm Cuộc đua diễn thời gian dài Tôi thấy đua vậy, đến 10 năm để kết thúc Và vào thời điểm đó, thành viên ban đầu nhóm nghỉ việc, thành viên yêu cầu thiết kế lại hệ thống code trở thành mớ lộn xộn Nếu bạn trải qua, dù phần nhỏ câu chuyện bên trên, hẳn bạn biết việc dành thời gian để giữ cho code đẹp khơng câu chuyện chi phí, mà cịn vấn đề sống cịn lập trình viên chuyên nghiệp Thay đổi cách nhìn Bạn bơi đống code lộn tùng phèo để nhận thay cần để xử lý nó, bạn lại tốn vài tuần? Hay thay ngồi lọ mọ sửa lỗi hàng trăm module, bạn cần tác động lên dòng code Nếu thật vậy, bạn khơng đơn, ngồi có hàng trăm ngàn lập trình viên bạn Tại chuyện lại xảy ra? Tại code đẹp lại nhanh chóng trở thành đống lộn xộn được? Chúng tơi có nhiều lời giải thích dành cho Chúng tơi phàn nàn cho u cầu thay đổi theo hướng ngăn cản thiết kế ban đầu hệ thống Chúng tơi rên lịch làm việc bận rộn Chúng chửi rủa nhà quản lý ngu ngốc khách hàng bảo thủ cách tiếp thị vô dụng Nhưng thưa Dilbert, lỗi không nằm mục tiêu mà hướng đến, lỗi nằm chúng ta, khơng chun nghiệp Đây thật không dễ chịu Bằng cách đống code rối tung rối mù lại lỗi chúng tơi? Các u cầu vơ lý sao? Còn lịch làm việc dày đặc? Và tên quản lý ngu ngốc, hay cách tiếp thị vô dụng – Không chịu trách nhiệm à? Câu trả lời KHÔNG Các nhà quản lý nhà tiếp thị tìm đến chúng tơi họ cần thơng tin để tạo lời hứa cam kết chương trình; họ khơng tìm chúng tơi, chúng tơi khơng ngại nói cho họ biết suy nghĩ Khách hàng tìm đến để xác thực yêu cầu phù hợp với hệ thống Các nhà quản lý tìm đến chúng tơi để giúp tạo lịch trình làm việc phù hợp Chúng mệt mỏi việc lập kế hoạch cho dự án phải nhận nhiều trách nhiệm thất bại, đặc biệt thất bại liên quan đến code lởm “Nhưng khoan!” – bạn nói – “Nếu tơi khơng làm mà sếp tơi bảo, bị sa thải” Ồ, không hẳn đâu Hầu hết ông sếp muốn thật, họ hành động trông không giống Những ơng sếp muốn chương trình code đẹp, dù họ bị ám ảnh lịch trình dày đặt Họ thay đổi lịch trình u cầu, cơng việc họ Đó cơng việc bạn – bảo vệ code niềm đam mê Để giải thích điều này, tưởng tượng bạn bác sĩ có bệnh nhân yêu cầu bạn ngưng việc rửa tay để chuẩn bị cho phẫu thuật, việc rửa tay nhiều thời gian Rõ ràng bệnh nhân thượng đế, bác sĩ từ chối yêu cầu Tại sao? Bởi bác sĩ biết nhiều bệnh nhân nguy bệnh tật nhiễm trùng Rõ ngu ngốc bác sĩ lại đồng ý với yêu cầu Tương tự vậy, nghiệp dư cho lập trình viên ln tn theo u cầu sếp – người nguy việc tạo chương trình đầy code rối Vấn đề nan giải Các lập trình viên phải đối mặt với vấn đề nan giải giá trị Những lập trình viên với năm kinh nghiệm biết đống code lộn xộn kéo họ xuống Tuy nhiên, tất họ cảm thấy áp lực tìm cách giải theo hạn Tóm lại, họ khơng dành thời gian để tạo nên hướng vững vàng Các chuyên gia thật biết phần thứ hai vấn đề sai, đống code lộn xộn giúp bạn hồn thành cơng việc hạn Thật vậy, lộn xộn làm chậm bạn lập tức, buộc bạn phải trễ thời hạn Cách để hoàn thành hạn – cách để bước vững vàng – giữ cho code ln bạn cịn Kỹ thuật làm code? Giả sử bạn tin code lởm chướng ngại đáng kể, giả sử bạn tin cách để có hướng vững vàng giữ code bạn, bạn cần tự hỏi thân : “Làm cách để viết code cho sạch?” Nếu bạn ý nghĩa việc code sạch, tốt bạn không nên viết Tin xấu là, việc tạo nên code giống cách vẽ nên tranh Hầu hết nhận đâu tranh đẹp, đâu tranh xấu – điều khơng có nghĩa biết cách vẽ Vậy nên, việc bạn lơi vài dịng code đẹp đống code lởm khơng có nghĩa biết cách viết nên dòng code Viết code yêu cầu khổ luyện liên tục kỹ thuật nhỏ khác nhau, cần cù đền đáp cảm giác “sạch sẽ” code Cảm giác (hay giác quan) chìa khóa, số người Chúa ban tặng từ sinh ra, số người khác phải đấu tranh để có Nó khơng cho phép xem xét code xịn hay lởm, mà cho thấy kỹ thuật áp dụng Một lập trình viên khơng có giác quan code khơng biết phải làm nhìn vào đống code rối Ngược lại, người có giác quan code bắt đầu nhìn cách để thay đổi Giác quan code giúp lập trình viên chọn cách tốt nhất, vạch đường đắn để hồn thành cơng việc Tóm lại, lập trình viên viết code “sạch đẹp” thật nghệ sĩ Họ tạo hệ thống thân thiện từ hình trống rỗng Code chi chi? Có thể có nhiều định nghĩa Vì vậy, chúng tơi vấn số lập trình viên tiếng giàu kinh nghiệm khái niệm này: Bjarne Stroustrup – cha đẻ ngôn ngữ C++, tác giả The C++ Programming Language: “Tơi thích code tơi trơng lịch hiệu Sự logic nên thể rõ ràng để làm cho lỗi khó lẫn trốn, phụ thuộc giảm thiểu để dễ bảo trì, lỗi xử lý chiến lược rõ ràng, hiệu gần tối ưu để khơng lơi kéo người khác tạo nên code rối cách tối ưu hóa tạm bợ Code tạo nên điều tuyệt vời” Bjarne sử dụng từ lịch Nó xác Từ điển Macbook tơi giải thích sau: vẻ đẹp dun dáng phong cách dễ chịu, đơn giản làm hài lòng người Hãy ý đến nội dung làm hài lòng Rõ ràng Bjarne cho code dễ đọc Đọc làm cho bạn mỉm cười nhẹ nhàng hộp nhạc Bjarne đề cập đến hiệu – hai lần Khơng có bất ngờ từ người phát minh C++, tơi nghĩ cịn nhiều điều mong muốn đạt hiệu suất tuyệt đối Các tài nguyên bị lãng phí, chuyện chẳng dễ chịu chút Và để ý đến từ mà Bjarne dùng để miêu tả hậu – lơi kéo Có thật là, code lởm “thu hút” đống code lởm khác Khi thay đổi đống code đó, họ có xu hướng làm cho tệ […] Bjarne đề cập đến việc xử lý lỗi phải thực đầy đủ Điều tạo nên thói quen ý đến chi tiết nhỏ Việc xử lý lỗi qua loa khiến lập trình viên bỏ qua chi tiết nhỏ: nguy tràn nhớ, tượng tranh giành liệu (race condition), hay đặt tên không phù hợp,…Vậy nên, việc code tạo tính kỹ lưỡng cho lập trình viên Bjarne kết thúc vấn khẳng định code tạo nên điều tuyệt vời Không phải ngẫu nhiên mà tơi lại nói – ngun tắc thiết kế phần mềm cô đọng lại lời khuyên đơn giản Tác giả sau viết cố gắng truyền đạt tư tưởng Code rởm tồn đủ lâu, khơng có lý để giữ tiếp tục Bây giờ, code tập trung phát triển Mỗi hàm, lớp, mô-đun thể độc lập, không bị nhiễm thứ quanh Grady Booch, tác giả Object Oriented Analysis and Design with Applications “Code đơn giản rõ ràng Đọc giống việc bạn đọc đoạn văn xuôi Code thể rõ ràng ý đồ lập trình viên, đồng thời mô tả rõ trừu tượng dòng điều khiển đơn giản” […] Dave Thomas, người sáng lập OTI, godfather of the Eclipse strategy: “Code đọc phát triển thêm lập trình viên khác Nó kiểm tra, có tên ý nghĩa, cho bạn thấy cách để làm việc Nó giảm thiểu phụ thuộc đối tượng với định nghĩa rõ ràng, cung cấp API cần thiết Code nên hiểu theo cách diễn đạt, tất thông tin cần thiết thể rõ ràng code” […] Michael Feathers, tác giả Working Effectively with Legacy Code: “Tơi liệt kê tất phẩm chất mà thấy code sạch, tất chúng bao quát điều – code trông viết người tận tâm Dĩ nhiên, bạn cho bạn làm tốt Điều họ (những người tạo code sạch) nghĩ đến, bạn cố gắng “rặn” cải tiến, đưa bạn lại vị trí ban đầu Ngồi xuống tơn trọng dịng code mà để lại cho bạn – dòng code viết người đầy tâm huyết với nghề” […] Ward Cunningham, người tạo Wiki: Hãy nhớ tới câu chuyện vui nghệ sĩ violin bị lạc đường tới buổi biểu diễn Anh hỏi ông già phố làm để đến Carnegie Hall (nơi xem thánh đường âm nhạc) Ơng già nhìn người nghệ sĩ violin giấu cánh tay anh ta, nói to: Luyện tập, trai Là luyện tập! Tham khảo Implementation Patterns, Kent Beck, Addison-Wesley, 2007 Literate Programming, Donald E Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992 13 CHƯƠNG *** NHỮNG CÁI TÊN RÕ NGHĨA Viết Tim Ottinger 14 Giới thiệu Những tên có khắp nơi phần mềm Chúng ta đặt tên cho biến, hàm, đối số, lớp gói Chúng ta đặt tên cho file mã nguồn thư mục chứa chúng Chúng ta đặt tên cho file *.jar, file *.war, Chúng ta đặt tên đặt tên Vì đặt tên nhiều, nên cần làm tốt điều Sau số quy tắc đơn giản để tạo nên tên tốt Dùng tên thể mục đích Điều dễ Nhưng muốn nhấn mạnh nghiêm túc việc Chọn tên “xịn” nhiều thời gian, lại tiết kiệm (thời gian) sau Vì vậy, quan tâm đến tên mà bạn chọn thay đổi chúng bạn sáng tạo tên “xịn” Những người đọc code bạn (kể bạn) sung sướng bạn làm điều Tên biến, hàm, lớp phải trả lời tất câu hỏi Nó phải cho bạn biết lý tồn tại, làm gì, dùng Nếu có comment kèm theo tên, tên khơng thể mục đích int d; // elapsed time in days Tên d không tiết lộ điều Nó khơng gợi lên cảm giác thời gian, khơng liên quan đến ngày Chúng ta nên chọn tên thể cân đo, đơn vị đo chúng: int int int int elapsedTimeInDays; daysSinceCreation; daysSinceModification; fileAgeInDays; Việc chọn tên thể mục đích làm cho việc hiểu thay đổi code dễ dàng nhiều Hãy đốn xem mục đích đoạn code gì? public List getThem() { List list1 = new ArrayList(); for (int[] x : theList) if (x[0] == 4) list1.add(x); return list1; } Tại lại nói khó mà biết đoạn code làm gì? Khơng có biểu thức phức tạp, khoảng cách cách thụt đầu dịng hợp lý, có biến số đề cập Thậm chí khơng có lớp (class) phương thức đa hình nào, có danh sách mảng (hoặc thứ trơng giống vậy) 15 Vấn đề khơng nằm đơn giản code mà nằm ý nghĩa code, bối cảnh không rõ ràng Đoạn code bắt chúng tơi phải tìm câu trả lời cho câu hỏi sau: theList chứa gì? Ý nghĩa số phần tử theList? Số có ý nghĩa gì? Danh sách return dùng kiểu gì? Câu trả lời khơng có code, có sau Giả sử chúng tơi làm game dị mìn Chúng tơi thấy giao diện trị chơi danh sách ô vuông (cell) gọi theList Vậy nên, đổi tên thành gameBoard Mỗi hình biểu diễn sanh sách đơn giản Chúng thấy số số vị trí biểu diễn giá trị trạng thái (status value), giá trị nghĩa trạng thái gắn cờ (flagged) Chỉ cách đưa khái niệm này, chúng tơi cải thiện mã nguồn cách đáng kể: public List getFlaggedCells() { List flaggedCells = new ArrayList(); for (int[] cell : gameBoard) if (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell); return flaggedCells; } Cần lưu ý mức độ đơn giản code không thay đổi, xác tốn tử, số, lệnh lồng nhau,…Nhưng trở nên rõ ràng nhiều Chúng ta xa cách viết lớp đơn giản cho ô thay sử dụng mảng kiểu int Nó bao gồm hàm thể mục đích (gọi isFlagged – gắn cờ chẳng hạn) để giấu số ma thuật (Từ gốc: magic number – Một khái niệm số, tìm hiểu thêm https://en.wikipedia.org/wiki/Magic_number_(programming) ) public List getFlaggedCells() { List flaggedCells = new ArrayList(); for (Cell cell : gameBoard) if (cell.isFlagged()) flaggedCells.add(cell); return flaggedCells; } Với thay đổi đơn giản này, khơng q khó để hiểu mà đoạn code trình bày Đây sức mạnh việc chọn tên tốt 16 Tránh sai lệch thơng tin Các lập trình viên phải tránh để lại dấu hiệu làm code trở nên khó hiểu Chúng ta nên tránh dùng từ mang nghĩa khác với nghĩa cố định Ví dụ, tên biến hp, aix sco tên biến vô tồi tệ, chúng tên tảng Unix biến thể Ngay bạn code cạnh huyền (hypotenuse) hp trông giống tên viết tắt tốt, tên tồi Không nên quy kết nhóm tài khoản accountList khơng thật danh sách (List) Từ danh sách có nghĩa thứ cụ thể cho lập trình viên Nếu tài khoản khơng thực tạo thành danh sách, dẫn đến kết sai lầm Vậy nên, accountGroup bunchOfAccounts, đơn giản accounts tốt Cẩn thận với tên gần giống Mất để bạn phân biệt khác XYZControllerForEfficientHandlingOfStrings XYZControllerForEfficientStorageOfStrings module, hay xa chút? Những tên gần giống thật sự, thật khủng khiếp cho lập trình viên Một kiểu khủng bố tinh thần khác tên không rõ ràng ký tự L viết thường O viết hoa Vấn đề? Tất nhiên nhìn chúng gần hồn tồn giống số không một, kiểu như: int a = l; if ( O == l ) a = O1; else l = 01; Bạn nghĩ xạo? Chúng khảo sát, kiểu code thực nhiều Trong số trường hợp, tác giả code đề xuất sử dụng phông chữ khác để tách biệt chúng Một giải pháp khác sử dụng truyền đạt lời nói để lại tài liệu cho lập trình viên sau hiểu Vấn đề giải mà không cần phải đổi tên để tạo sản phẩm khác Tạo nên khác biệt có nghĩa Các lập trình viên tạo vấn đề cho họ viết code để đáp ứng cho trình biên dịch thơng dịch Ví dụ, bạn sử dụng tên để hai thứ khác khối lệnh phạm vi, bạn bị “dụ dỗ” thay đổi tên cách tùy tiện Đôi điều làm bạn cố tình viết sai tả, người định sửa lỗi tả đó, khiến trình biên dịch khơng có khả hiểu (cụ thể – tạo biến tên klass tên class dùng cho thứ đó) Mặc dù trình biên dịch làm việc với tên này, điều khơng có nghĩa bạn phép dùng Nếu tên khác nhau, chúng có ý nghĩa khác 17 Những tên dạng chuỗi số (a1, a2,… aN) ngược lại nguyên tắc đặt tên có mục đích Mặc dù tên không đúng, chúng thơng tin Chúng khơng cung cấp manh mối ý định tác giả Ví dụ: public static void copyChars(char a1[], char a2[]) { for (int i = 0; i < a1.length; i++) { a2[i] = a1[i]; } } Hàm dễ đọc nhiều nguyên nhân mục đích đặt tên cho đối số Những từ gây nhiễu tạo nên khác biệt, khác biệt vô dụng Hãy tưởng tượng bạn có lớp Product, bạn có ProductInfo ProductData khác, bạn thành cơng việc tạo tên khác mặt ngữ nghĩa chúng Info Data từ gây nhiễu, giống a, an the Lưu ý khơng có sai sử dụng tiền tố a the để tạo khác biệt hữu ích Ví dụ, bạn sử dụng a cho tất biến cục tất đối số hàm a the trở thành vô dụng bạn định tạo biến theZork trước bạn có biến mang tên Zork Những từ gây nhiễu không cần thiết Từ variable không xuất tên biến, từ table không nên dùng tên bảng NameString lại tốt Name? Name có số đâu mà lại? Nếu Name số, phá vỡ nguyên tắc Tránh sai lệch thông tin Hãy tưởng tượng bạn tìm kiếm lớp có tên Customer, lớp khác có tên CustomerObject Chúng khác kiểu gì? Cái chứa lịch sử toán khách hàng? Cịn chứa thơng tin khách? Có ứng dụng minh họa cho lỗi trên, thay đổi chút tên để bảo vệ tác giả Đây thứ thấy mã nguồn: getActiveAccount(); getActiveAccounts(); getActiveAccountInfo(); Tôi thắc mắc lập trình viên dự án phải getActiveAccount nào! Trong trường hợp khơng có quy ước cụ thể, biến moneyAmount phân biệt với money; customerInfo phân biệt với customer; accountData phân biệt với account theMessage với message xem Hãy phân biệt tên theo cách cung cấp cho người đọc khác biệt rõ ràng 18 Dùng tên phát âm Con người giỏi từ ngữ Một phần quan trọng não dành riêng cho khái niệm từ Và từ, theo định nghĩa, phát âm Thật lãng phí khơng sử dụng não mà tiến hóa nhằm thích nghi với ngơn ngữ nói Vậy nên, làm cho tên phát âm Nếu bạn khơng thể phát âm nó, bạn khơng thể thảo luận cách bình thường: “Hey, có bee cee arr three cee enn tee, pee ess zee kyew int, thấy chứ?” – Vâng, thấy thằng thiểu Vấn đề quan trọng lập trình hoạt động xã hội, cần trao đổi với người Tơi có biết cơng ty dùng tên genymdhms (generation date, year, month, day, hour, minute, and second – phát sinh ngày, tháng, năm, giờ, phút, giây), họ xung quanh “gen why emm dee aich emm ess” (cách phát âm theo tiếng Anh) Tơi có thói quen phát âm tơi viết, tơi bắt đầu nói “gen-yah-muddahims” Sau gọi loạt nhà thiết kế phân tích, nghe ngớ ngẫn Chúng tơi troll thế, thú vị Nhưng nữa, chấp nhận tên xấu xí Những lập trình viên cơng ty tìm hiểu ý nghĩa biến, sau họ nói từ ngớ ngẫn, thay dùng thuật ngữ tiếng Anh cho thích hợp Hãy so sánh: class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszqint = "102"; /* */ }; class Customer { private Date generationTimestamp; private Date modificationTimestamp; private final String recordId = "102"; /* */ }; Cuộc trị chuyện thơng minh hơn: “Hey, Mikey, take a look at this record! The generation timestamp is set to tomorrow’s date! How can that be?” Dùng tên tìm kiếm Các tên chữ số ln có vấn đề, khơng dễ để tìm chúng hàng ngàn dịng code 19 Người ta dễ dàng tìm kiếm MAX_CLASSES_PER_STUDENT, số lại rắc rối Các cơng cụ tìm kiếm mở tệp, hằng, biểu thức chứa số này, sử dụng với mục đích khác Thậm chí cịn tồi tệ số số có giá trị lớn vơ tình thay đổi giá trị nó, từ tạo lỗi mà lập trình viên khơng tìm Tương tự vậy, tên e lựa chọn tồi tệ cho biến mà lập trình viên cần tìm kiếm Nó chữ phổ biến tiếng anh có khả xuất đoạn code chương trình Về vấn đề này, tên dài tốt tên ngắn, tên tìm kiếm tốt số trơ trọi code Sở thích cá nhân tơi đặt tên ngắn cho biến cục bên phương thức ngắn Độ dài tên phải tương ứng với phạm vi hoạt động Nếu biến số nhìn thấy sử dụng nhiều vị trí phần thân mã nguồn, bắt buộc phải đặt cho tên dễ tìm kiếm Ví dụ: for (int j=0; j