Giới thiệu
Các lập trình viên luôn luôn thích chống lại code chuẩn. Nhưng nó rất quan trọng để theo code chuẩn để đạt được sự nhất quán trong suốt dự án hoặc code. Tất cả nên theo quy ước. Tôi sẽ giới thiệu một số kiểu code tốt mà tôi đã học được và nhận ra được đâu là code tốt code đúng quy chuẩn thay vì code vô tội vạ code chỉ để chạy. Bài hướng dẫn này đơn giản, hầu hết người lập trình bình thường nào cũng có thể học.
Quick test
Đầu tiên, tôi sẽ đưa ra một bài ví dụ FizzBuzz. FizzBuzz tức là là viết một chương trình chạy từ 1 đến 100 số. Đối với mỗi bội số của 3, chương trình phải in ra "Fizz" và lớn hơn 5 phải in ra "Buzz". Nếu cả hai điều kiện trên là gặp phải in ra "FizzBuzz" Nếu không có các điều kiện trên được đáp ứng, nó chỉ ra số lượng.
Ví dụ 1:
Có lẽ bạn sẽ nghĩ code như vậy là được rồi, cần gì phải thay đổi? Tôi sẽ hướng dẫn bạn code tốt hơn.
Ví dụ 2:
Bạn nghĩ gì? Code này đã thật sự tốt hơn chưa?
OK, hãy để tôi giúp bạn làm tốt hơn. Việc đặt tên là thật sự khó với 1 số người, đặc biệt đối với lập trình viên không chuyên. Hầu như thời gian của lập trình viên là định nghĩa cho nó, tên thuộc tính, phương thức, lớp, dự án,… Tên phải ý nghĩa và đọc hiểu code.
Ví dụ 3:
Bạn nghĩ gì? Code này tốt hơn ví dụ trước? Dễ đọc hơn, dễ dàng kiểm soát hơn? Đó là cách viết code.
Có nhiều người hỏi, thế viết code tốt hơn để làm gì?
Người viết code giỏi không phải viết code chỉ để mình đọc, mình hiểu, mà viết code ra để cho người khác đọc và hiểu được.
Điều gì sẽ xảy ra nếu bạn chỉ viết mã cho chính mình? Tại sao bạn phải viết mã cho người khác đọc được?
Câu hỏi này thể hiện sự thống nhất ngay từ bây giờ. Vì khi bước vào dự án, công việc của mình đi kèm với cả nhóm, đòi hỏi phải thống nhất ngay từ đầu. Những dòng mã mình viết ra, có thể sẽ được người khác thừa hưởng hoặc nâng cấp hoặc chỉ để hiểu. Một dự án mà thiếu đi sự thống nhất, coi như dự án đó về cơ bản đã sụp đổ, thất bại hoàn toàn.
Từ quan điểm đó Tôi có nhận định sau:
- Code phải dễ viết, sửa đổi và nâng cấp
- Code phải sạch sẽ, có chú thích và mang ý nghĩa
- Code phải có giá trị và quan tâm tới chất lượng
Làm thế nào bạn có thể cải thiện khả năng đọc
Trước tiên bạn phải đọc mã của người khác, và tìm ra những gì là tốt những gì là xấu trong đoạn mã đó. Điều gì làm bạn dễ hiểu và những gì làm cho bạn cảm thấy phức tạp. Sau đó, áp dụng những kinh nghiệm, cảm nhận để đưa ra mã của riêng mình. Nó là rất khó, nó thực sự không có quy chuẩn của bất kỳ công ty phần mềm nào, thông qua các phương thức như đào tạo, xét mãn ngang hàng, giới thiệu các công cụ review code tự động, … hầu hết các Tool phổ biến sau:
FxCop là công cụ thực hiện phân tích mã tĩnh .NET. Nó cung cấp hàng trăm quy tắc thực hiện phân tích
StyleCop là dự án mã nguồn mở phân tích mã nguồn C# để thực thi 1 bộ quy tắc style và tính nhất quán. Nó có thể được chạy trong Visual Studio hoặc được tích hợp vào dự án MSBuild. StyleCop cũng được tích hợp vào nhiều công cụ phát triển của bên thứ ba.
Quy ước?
Bạn cần biết sự khác nhau giữa tên thuộc tính, biến, phương thức, lớp,… Bởi chúng được sử dụng với quy ước khác nhau. Bạn có thể dễ dàng nhận hướng dẫn và quy ước thông qua internet. Vì vậy, hãy tìm quy ước hoặc xây dựng cho riêng bạn và gắn bó với nó.
Thực hiện
Dưới đây là ví dụ C# theo chuẩn.
Casing Pascal
Viết hoa chữ cái đầu tiên và chữ cái đầu của mỗi từ nối tiếp theo.
Casing Camel
Chữ cái đầu tiên là chữ thường và chữ cái đầu tiên của mỗi từ nối tiếp theo là viết hoa.
Một số cách đặt tên
Tôi Cung cấp một số ví dụ mức độ cơ bản dưới đây, nhưng như tôi đã đề cập, tìm thấy một quy ước tốt phù hợp cho bạn và gắn bó với nó.
Trường hợp sử dụng PascalCasing cho tên lớp và tên phương thức.
public class Product
{
public void GetActiveProducts()
{
//...
}
public void CalculateProductAdditinalCost()
{
//...
}
}
Trường hợp sử dụng camelCasing cho các đối số phương thức và các biến địa phương.
public class ProductCategory
{
public void Save(ProductCategory productCategory)
{
// ...
}
}
KHÔNG sử dụng từ viết tắt
// Correct
ProductCategory productCategory;
// Avoid
ProductCategory prodCat;
KHÔNG sử dụng gạch dưới trong định danh
// Correct
ProductCategory productCategory;
// Avoid
ProductCategory product_Category;
Trường hợp tiền tố interfaces cùng với chữ.
public interface IAddress
{
}
Trường hợp khai báo tất cả các biến thành viên ở phía trên cùng của một lớp, với các biến tĩnh ở đầu.
public class Product
{
public static string BrandName;
public string Name{get; set;}
public DateTime DateAvailable {get; set;}
public Product()
{
// ...
}
}
Trường hợp sử dụng sử dụng tên số ít cho enums. Ngoại trừ: bit field enums.
public enum Direction
{
North,
East,
South,
West
}
Không sử dụng hậu tố tên enum với Enum
//Avoid
public enum DirectionEnum
{
North,
East,
South,
West
}
Tại sao chúng ta cần quy ước?
Quy ước cung cấp một vài lợi ích cụ thể. Chúng cho phép bạn có nhiều hơn bằng cách quyết định toàn cầu chứ không phải cục bộ, bạn có thể tập trung vào các đặc điểm quan trọng của mã này.
- Chúng giúp bạn chuyển giao kiến thức qua các dự án
- Chúng giúp bạn tìm hiểu mã nhanh chóng trên một dự án mới.
- Chúng nhấn mạnh mối quan hệ trong số các item liên quan.
Lập trình các dự án lớn đôi khi overboard với các quy ước. Các máy tính không quan tâm chuyển tiếp mã của bạn là có thể đọc được. Nó là tốt hơn đọc hướng dẫn máy nhị phân hơn ngôn ngữ cấp cao.