15 nguyên tắc để nâng cao chất lượng code

Giới thiệu

Có vô số cách viết mã kém. Rất may , chúng ta đã tìm ra 15 cách, để nâng cao chất lượng code. Theo dõi họ sẽ không biến bạn thành một lập trình viên bậc thầy, nhưng sẽ cho phép bạn giả mạo một cách khá thuyết phục.

Quy tắc 1: Thực hiện theo Style Guide

Mỗi ngôn ngữ lập trình đều có một style guide cho bạn biết rất chi tiết về cách thụt mã của bạn, nơi đặt dấu cách và dấu ngoặc, cách đặt tên, cách nhận xét về tất cả các thực tiễn tốt và xấu. Ví dụ: hướng dẫn kiểu cho bạn biết 12 lỗi ẩn trong đoạn mã này:

for (i = 0; i <10; i ++) {

Đọc hướng dẫn cẩn thận, tìm hiểu những điều cơ bản, tìm kiếm các trường hợp một cách cẩn thận, áp dụng các quy tắc một cách chặt chẽ, và các chương trình của bạn sẽ tốt hơn so với những gì được viết bởi phần lớn các sinh viên tốt nghiệp đại học.

Nhiều tổ chức tùy chỉnh style guide để phản ánh thực tiễn cụ thể của tổ chức. Chẳng hạn, Google đã phát triển và phát hành các hướng dẫn về phong cách (style) cho hơn một chục ngôn ngữ. Các hướng dẫn này được cân nhắc kỹ lưỡng, vì vậy hãy xem chúng nếu bạn đang tìm kiếm chương trình trợ giúp cho Google. Các hướng dẫn thậm chí bao gồm các cài đặt trình chỉnh sửa để giúp bạn áp dụng kiểu lập trình và các công cụ tùy chỉnh có thể xác minh rằng mã của bạn tuân thủ kiểu đó. Hãy sử dụng các công cụ này.

Quy tắc 2: Tạo tên mô tả, tên gợi nhớ

Bị hạn chế bởi các máy tính chậm, cồng kềnh, các lập trình viên trước đây thường sử dụng tên của các biến và thói quen của họ để tiết kiệm thời gian, tổ hợp phím, mực và giấy. Văn hóa này vẫn tồn tại trong một số cộng đồng, hãy xem xét hàm wcscspn (chuỗi ký tự bổ sung chuỗi ký tự rộng) của C. Nhưng không có lý do cho hàm này được sử dụng trong code hiện đại.

Sử dụng các tên mô tả dài, như complementSpanLength , để giúp bản thân bạn, bây giờ và trong tương lai, cũng như các đồng nghiệp của bạn để hiểu mã này làm gì. Ngoại lệ duy nhất cho quy tắc này liên quan đến một vài biến chính được sử dụng trong phần thân của phương thức, chẳng hạn như chỉ số vòng lặp, tham số, kết quả trung gian hoặc giá trị trả về.

Thậm chí quan trọng hơn, suy nghĩ lâu và chăm chỉ trước khi bạn đặt tên cho một cái gì đó. Tên có chính xác không? Ý của bạn là highprice , hơn là bestprice ? Là tên cụ thể đủ để tránh mất nhiều hơn so với phần không gian ngữ nghĩa của nó? Bạn có nên đặt tên cho phương thức của mình là getBestprice , thay vì getBest không? Liệu hình thức của nó phù hợp với tên tương tự khác? Nếu bạn có một phương thức ReadEventLog , bạn không nên đặt tên cho NetErrorLogRead khác . Nếu bạn đang đặt tên cho một chức năng, tên có mô tả những gì chức năng trả về không?

Cuối cùng, có một số quy tắc đặt tên dễ dàng. Tên lớp và loại nên là danh từ. Tên phương thức nên chứa một động từ. Đặc biệt, nếu một phương thức trả về một giá trị chỉ ra cho dù điều gì đó đúng đối với một đối tượng, tên phương pháp nên bắt đầu với is . Các phương thức khác trả về thuộc tính của đối tượng nên bắt đầu bằng get và các phương thức đặt thuộc tính sẽ bắt đầu bằng set .

Quy tắc 3: Comment and Document

Bắt đầu mọi thói quen bạn viết (hàm hoặc phương thức) bằng một document phác thảo những gì thường trình làm, các tham số của nó và những gì nó trả về, cũng như các lỗi và ngoại lệ có thể xảy ra. Tóm tắt trong một comment về vai trò của từng tệp (file) và lớp (class), nội dung của từng trường lớp và các bước chính của mã phức tạp. Viết các ý kiến ​​khi bạn phát triển mã; nếu bạn nghĩ bạn sẽ thêm chúng sau, bạn đang tự đùa.

Ngoài ra, đảm bảo rằng toàn bộ mã của bạn (ví dụ: ứng dụng hoặc thư viện) đi kèm với ít nhất một hướng dẫn giải thích những gì nó làm; chỉ ra sự phụ thuộc của nó; và cung cấp hướng dẫn về xây dựng, thử nghiệm, cài đặt và sử dụng. Tài liệu này nên ngắn gọn và ngọt ngào; một tệp README thường là đủ.

Quy tắc 4: Đừng lặp lại chính mình

Không bao giờ sao chép và dán mã. Thay vào đó, trừu tượng các phần phổ biến thành một thường trình hoặc lớp (hoặc macro, nếu bạn phải) và sử dụng nó với các tham số thích hợp. Rộng hơn, tránh các trường hợp trùng lặp của dữ liệu hoặc mã tương tự. Giữ một phiên bản dứt khoát ở một nơi và để phiên bản đó thúc đẩy tất cả các mục đích sử dụng khác. Sau đây là một số ví dụ tốt về thực hành này:

  • Tạo hướng dẫn tham chiếu API từ các nhận xét, sử dụng Javadoc hoặc Doxygen
  • Tự động phát hiện các bài kiểm tra đơn vị (unit test) thông qua một chú thích hoặc quy ước đặt tên
  • Tạo cả tài liệu PDF và HTML từ một nguồn đánh dấu duy nhất
  • Thiết kế các lớp đối tượng từ một lược đồ cơ sở dữ liệu (hoặc ngược lại)

Quy tắc 5: Kiểm tra lỗi và trả lời chúng

Các thường trình có thể trở lại với một dấu hiệu lỗi hoặc chúng có thể đưa ra một ngoại lệ. Đối phó với nó. Đừng cho rằng ổ cứng sẽ không bao giờ lấp đầy, tệp cấu hình của bạn sẽ luôn ở đó, ứng dụng của bạn sẽ chạy với các quyền cần thiết, yêu cầu cấp phát bộ nhớ sẽ luôn thành công hoặc kết nối sẽ không bao giờ hết. Có, xử lý lỗi tốt rất khó viết và nó làm cho mã dài hơn và ít đọc hơn. Nhưng bỏ qua các lỗi và ngoại lệ chỉ đơn giản là quét các vấn đề một cách giải thảm, nơi một người dùng cuối không nghi ngờ chắc chắn sẽ tìm thấy nó một ngày nào đó.

Quy tắc 6: Chia mã của bạn thành các đơn vị ngắn, tập trung

Mọi phương thức, chức năng hoặc khối mã logic phải phù hợp với cửa sổ màn hình có kích thước hợp lý (dài 25 dòng50). Nếu nó dài hơn, hãy chia nó thành các phần ngắn hơn. Một ngoại lệ có thể được thực hiện cho các chuỗi mã lặp đi lặp lại đơn giản. Tuy nhiên, trong những trường hợp như vậy, hãy xem xét liệu bạn có thể lái mã đó qua bảng dữ liệu hay không. Ngay cả trong một thói quen, hãy chia các chuỗi mã dài thành các khối có chức năng mà bạn có thể mô tả bằng một nhận xét ở đầu mỗi khối.

Hơn nữa, mỗi lớp, mô-đun, tệp hoặc quy trình nên liên quan đến một điều duy nhất. Nếu một đơn vị mã đảm nhận các trách nhiệm khác nhau, hãy phân chia nó cho phù hợp.

Quy tắc 7: Sử dụng API khung và thư viện của bên thứ ba

Tìm hiểu chức năng nào có sẵn thông qua API trong khung lập trình của bạn và cũng là chức năng thường có sẵn thông qua các thư viện bên thứ ba đã phát triển, được chấp nhận rộng rãi. Các thư viện được hỗ trợ bởi người quản lý gói hệ thống của bạn thường là một lựa chọn tốt. Sử dụng mã đó, chống lại sự cám dỗ để phát minh lại bánh xe (trong một hình vuông rối loạn chức năng).

Quy tắc 8: Đừng quá mức

Giữ thiết kế của bạn tập trung vào nhu cầu ngày nay. Mã của bạn có thể nói chung để phù hợp với sự phát triển trong tương lai, nhưng chỉ khi điều đó không làm cho nó phức tạp hơn. Đừng tạo các lớp được tham số hóa, phương thức xuất xưởng, hệ thống phân cấp kế thừa sâu và giao diện phức tạp để giải quyết các vấn đề chưa tồn tại. Bạn không thể đoán được ngày mai sẽ mang lại điều gì. Mặt khác, khi cấu trúc của mã không còn phù hợp với nhiệm vụ trong tay, đừng ngại tái cấu trúc nó thành một thiết kế phù hợp hơn.

Quy tắc 9: Kiên định

Làm những điều tương tự theo những cách tương tự. Nếu bạn đang phát triển một thường trình có chức năng tương tự như một thói quen hiện có, hãy sử dụng một tên tương tự, cùng thứ tự tham số và cấu trúc có thể so sánh cho thân mã. Quy tắc tương tự áp dụng cho các lớp: Cung cấp cho các trường và phương thức tương tự lớp mới, làm cho nó tuân thủ cùng một giao diện và khớp bất kỳ tên mới nào với các tên đã được sử dụng trong các lớp tương tự. Tạo thứ tự và số lượng báo cáo trường hợp hoặc nếu các khối khác tuân theo định nghĩa tương ứng trong thông số kỹ thuật bạn đang sử dụng. Giữ các mục không liên quan theo thứ tự chữ cái hoặc số.

Mã của bạn nên áp dụng các quy ước của khung mà bạn đang lập trình. Chẳng hạn, thực tế phổ biến để biểu thị các phạm vi nửa mở: đóng (bao gồm) ở bên trái (bắt đầu của phạm vi), nhưng mở (độc quyền) ở bên phải (cuối). Nếu không có quy ước cho một lựa chọn cụ thể, hãy thiết lập một và tuân theo tôn giáo.

Quy tắc 10: Tránh các cạm bẫy an ninh

Mã hiện đại hiếm khi hoạt động trong sự cô lập. Do đó, chắc chắn sẽ có nguy cơ trở thành mục tiêu của các cuộc tấn công độc hại. Họ không phải đến từ Internet; vector tấn công có thể là dữ liệu được đưa vào ứng dụng của bạn. Tùy thuộc vào ngôn ngữ lập trình và miền ứng dụng của bạn, bạn có thể phải lo lắng về lỗi tràn bộ đệm, tập lệnh chéo trang, SQL SQL và các vấn đề tương tự. Tìm hiểu những vấn đề này là gì và tránh chúng trong mã của bạn. Nó không khó.

Quy tắc 11: Sử dụng các thuật toán và cấu trúc dữ liệu hiệu quả

Mã đơn giản thường dễ bảo trì hơn mã tương đương được điều chỉnh bằng tay cho hiệu quả. May mắn thay, bạn có thể kết hợp khả năng bảo trì với hiệu quả bằng cách sử dụng các cấu trúc dữ liệu và thuật toán được cung cấp bởi khung lập trình của bạn. Sử dụng map, set, vectơ và các thuật toán hoạt động trên chúng và mã của bạn sẽ rõ ràng hơn, có thể mở rộng hơn, nhanh hơn và tiết kiệm bộ nhớ. Ví dụ: nếu bạn giữ một nghìn giá trị trong một tập hợp có thứ tự, một giao điểm được đặt sẽ tìm thấy các giá trị chung với một tập hợp khác trong một số thao tác tương tự, thay vì thực hiện một triệu so sánh.

Quy tắc 12: Bao gồm các bài kiểm tra đơn vị

Sự phức tạp của phần mềm hiện đại khiến cho việc triển khai một hệ thống trở nên tốn kém và khó kiểm tra nó như một hộp đen. Một cách tiếp cận hiệu quả hơn là đi kèm với mọi phần nhỏ trong mã của bạn với các bài kiểm tra xác minh chức năng chính xác của nó. Cách tiếp cận này đơn giản hóa việc gỡ lỗi bằng cách cho phép bạn bắt lỗi sớm, gần với nguồn của chúng. Kiểm tra đơn vị là không thể thiếu khi bạn lập trình với các ngôn ngữ được gõ động như Python và JavaScript, bởi vì chúng sẽ chỉ bắt gặp trong thời gian chạy bất kỳ lỗi nào mà ngôn ngữ được nhập tĩnh như Java, C # hoặc C ++ sẽ mắc phải trong thời gian biên dịch. Kiểm thử đơn vị cũng cho phép bạn tự động cấu trúc lại mã. Bạn có thể sử dụng khung xUnit để đơn giản hóa việc viết các bài kiểm tra này và tự động hóa việc chạy chúng.

Quy tắc 13: Giữ mã của bạn di động

Trừ khi bạn có một số lý do thuyết phục, hãy tránh sử dụng chức năng chỉ có trên một nền tảng hoặc khung cụ thể. Đừng cho rằng các loại dữ liệu cụ thể (như số nguyên, con trỏ và thời gian) có độ rộng nhất định (ví dụ: 32 bit), vì điều này khác nhau giữa các nền tảng khác nhau. Lưu trữ các thông điệp của chương trình tách biệt với mã và không sử dụng các quy ước văn hóa mã hóa cứng như dấu phân cách thập phân hoặc định dạng ngày. Các quy ước cần thay đổi khi mã của bạn chạy ở các quốc gia khác trên thế giới, vì vậy hãy giữ sự thích ứng này càng ít càng tốt.

Quy tắc 14: Làm cho mã của bạn có thể xây dựng được

Một lệnh sẽ tạo mã của bạn thành một dạng sẵn sàng để phân phối. Lệnh sẽ cho phép bạn thực hiện các bản dựng gia tăng nhanh và chạy các bài kiểm tra cần thiết. Để đạt được mục tiêu này, hãy sử dụng một công cụ tự động hóa xây dựng như Make , Apache Maven hoặc Ant . Tốt nhất, bạn nên thiết lập một hệ thống tích hợp liên tục sẽ kiểm tra, xây dựng và kiểm tra mã của bạn mỗi khi bạn thực hiện thay đổi.

Quy tắc 15: Đặt mọi thứ dưới sự kiểm soát phiên bản

Tất cả các yếu tố của mã hệ thống của bạn, tài liệu, nguồn công cụ, tập lệnh xây dựng, dữ liệu thử nghiệm nên được kiểm soát phiên bản. Git và GitHub làm cho nhiệm vụ này rẻ và không rắc rối, nhưng nhiều công cụ và dịch vụ mạnh mẽ tương tự khác có sẵn. Bạn sẽ có thể xây dựng và kiểm tra chương trình của mình trên một hệ thống được cấu hình đúng, chỉ cần kiểm tra mã từ kho lưu trữ.

Tóm lược

Bằng cách biến 15 quy tắc này thành một phần của các hoạt động lập trình hàng ngày của bạn, cuối cùng bạn sẽ tạo ra mã dễ đọc hơn, được kiểm tra kỹ lưỡng, có khả năng chạy chính xác hơn và đơn giản hơn nhiều để sửa đổi khi thời điểm đó đến. Bạn cũng sẽ tự cứu mình và người dùng chương trình của bạn rất nhiều vấn đề đau đầu.