Mẹo C# ngắn gọn là thứ nhiều lập trình viên .NET tìm kiếm mỗi ngày, nhất là khi vừa bước vào nghề và chưa có thời gian đọc hết một cuốn tài liệu dày. Đội ngũ chúng tôi đã gom lại những kỹ thuật thực sự được dùng trong dự án thật, không phải lý thuyết trên giấy. Mỗi mẹo đều kèm ví dụ và lý do vì sao nó hiệu quả, để bạn áp dụng được ngay.
Có một điều cần nói rõ trước: mẹo hay không có nghĩa là lúc nào cũng dùng. C# cho phép giải quyết cùng một bài toán theo nhiều cách khác nhau. Điều khó nằm ở chỗ chọn đúng cách cho đúng tình huống. Vì vậy, sau mỗi mẹo, chúng tôi luôn ghi thêm phần lưu ý thay vì chỉ liệt kê cú pháp.
Vì sao những mẹo C# ngắn gọn lại đáng để tâm
Code trong dự án thực tế thường phình to theo thời gian. Ban đầu một class chỉ vài chục dòng, sau vài tháng thêm tính năng, nó dài cả trăm dòng và khó đọc hơn hẳn. Chúng tôi từng nhận bàn giao một dự án ASP.NET mà một file Controller có hơn 40 phương thức, và phương thức nào cũng lặp lại đúng một kiểu kiểm tra null giống hệt nhau.
Sau khi áp dụng vài mẹo nhỏ để rút gọn logic, số dòng code giảm rõ rệt trong khi độ rõ ràng tăng lên. Đó là giá trị thật của những mẹo này: không phải để khoe kỹ thuật, mà để code dễ bảo trì hơn cho chính bạn và đồng đội về sau. Nếu bạn muốn tìm hiểu sâu hơn về việc siết hiệu năng ở tầng ứng dụng, hãy đọc thêm các điểm dev hay bỏ qua khi tối ưu hiệu năng .NET để có cái nhìn toàn diện hơn.
Mẹo 1: Dùng string interpolation thay vì nối chuỗi thủ công
Nhiều bạn vẫn quen nối chuỗi bằng dấu cộng, kiểu “Xin chào ” + ten + “, bạn có ” + soDon + ” đơn hàng”. Cách này không sai, nhưng khi chuỗi dài thì rất khó đọc và dễ làm rơi khoảng trắng.
Chúng tôi thường khuyên dùng string interpolation với dấu $ ở đầu chuỗi: $”Xin chào {ten}, bạn có {soDon} đơn hàng”. Mắt bạn nhìn là thấy ngay biến nào được chèn ở đâu, không phải đếm dấu ngoặc hay dấu cộng. Với số tiền hay ngày tháng, bạn còn định dạng ngay trong ngoặc nhọn, ví dụ {gia:C}, nên không cần gọi ToString riêng.
Lưu ý nhỏ: nếu bạn đang nối chuỗi trong một vòng lặp lớn, hãy cân nhắc StringBuilder. Mỗi lần nối sẽ tạo ra một object string mới trong bộ nhớ, và số lượng lớn thì sẽ thấy chi phí rõ ràng.
Mẹo 2: Tận dụng toán tử null-conditional và null-coalescing
NullReferenceException gần như là nỗi ám ảnh chung của dân .NET. Cách xử lý cũ thường là lồng nhiều câu if để kiểm tra từng cấp, vừa dài vừa dễ bỏ sót một chỗ.
C# cho phép rút gọn bằng dấu chấm hỏi. Biểu thức khachHang?.DiaChi?.ThanhPho sẽ trả về null nếu bất kỳ cấp nào ở giữa là null, thay vì ném lỗi. Kết hợp với ??, bạn gán luôn giá trị mặc định: string thanhPho = khachHang?.DiaChi?.ThanhPho ?? “Chưa cập nhật”;
Đội ngũ chúng tôi dùng cách này rất nhiều khi xử lý dữ liệu trả về từ API bên thứ ba, vì những dữ liệu đó hiếm khi đầy đủ mọi trường. Chỉ vài dòng thay cho cả đống if-else, code vừa gọn vừa an toàn hơn.
Mẹo 3: Pattern matching giúp logic rẽ nhánh rõ ràng hơn
Từ C# 7 trở đi, pattern matching đã đổi cách chúng ta viết switch. Thay vì chỉ so sánh giá trị như trước, giờ bạn có thể kiểm tra cả kiểu dữ liệu lẫn điều kiện trong cùng một biểu thức.
Ví dụ khi xử lý một object hình học mà bạn chưa biết chắc kiểu, bạn có thể viết switch expression vừa kiểm tra kiểu vừa tính diện tích tương ứng. Không cần viết is rồi ép kiểu ở từng nhánh như trước.
Cách này không chỉ ngắn hơn. Trình biên dịch còn cảnh báo khi bạn thiếu một trường hợp xử lý, điều mà switch case cũ không làm được. Lúc mới học, cú pháp có thể hơi lạ, nhưng dùng vài lần là bạn sẽ thấy dễ đọc hơn nhiều so với một chuỗi if-else dài.
Mẹo 4: Dùng LINQ đúng lúc, đừng lạm dụng
LINQ là thứ làm việc với danh sách và tập dữ liệu trong C# trở nên dễ chịu hơn nhiều. Một dòng danhSach.Where(x => x.TrangThai == “Active”).OrderBy(x => x.Ten) có thể thay cho cả chục dòng vòng lặp for truyền thống.
Tuy vậy, chúng tôi cũng từng gặp trường hợp ngược lại: một đoạn xử lý bị nhồi đến năm sáu phương thức LINQ nối nhau trên cùng một dòng, đọc mãi không hiểu thứ tự xử lý là gì. Lúc đó, tách ra vài biến trung gian có tên rõ nghĩa lại dễ đọc hơn nhiều.
Với tập dữ liệu lớn, cũng cần cẩn thận vì LINQ trên IEnumerable chạy theo kiểu deferred execution, tức là câu lệnh chỉ thực sự chạy khi bạn duyệt kết quả. Nếu không để ý, bạn có thể vô tình truy vấn cơ sở dữ liệu nhiều lần hơn cần thiết, nhất là khi dùng Entity Framework.
Mẹo 5: Biết khi nào dùng var, khi nào khai báo kiểu rõ ràng
Từ khóa var làm code gọn hơn, điều đó không có gì phải bàn. Nhưng dùng var ở mọi nơi thì đôi khi người đọc phải đoán kiểu dữ liệu, nhất là khi tên phương thức không gợi ý được gì.
Quan điểm của đội ngũ khá đơn giản: dùng var khi kiểu đã hiển nhiên ở vế phải, ví dụ var danhSach = new List<KhachHang>(). Còn khi kết quả đến từ một phương thức có tên mơ hồ, hoặc khi bạn review code cho người mới, nên khai báo kiểu tường minh để tránh hiểu nhầm.
Một tình huống thực tế đội ngũ từng xử lý
Có lần chúng tôi nhận sửa lỗi hiệu năng cho một API ASP.NET của khách hàng. Thời gian phản hồi trung bình chậm bất thường vào giờ cao điểm. Sau khi rà lại code, chúng tôi thấy phần xử lý danh sách đơn hàng đang dùng foreach và truy vấn cơ sở dữ liệu ngay bên trong từng vòng lặp, thay vì gộp thành một truy vấn duy nhất.
Chúng tôi gom truy vấn lại bằng LINQ, rồi dùng thêm null-conditional để bỏ vài lớp kiểm tra thừa. Số lần gọi xuống cơ sở dữ liệu giảm đáng kể. Đây là minh chứng rõ rệt rằng một mẹo tưởng nhỏ, dùng đúng chỗ, có thể tạo khác biệt thực sự về hiệu năng chứ không chỉ là chuyện thẩm mỹ.
Nếu bạn đang cân nhắc thuê ngoài cho những bài toán tương tự, nên tìm hiểu kỹ trước khi ký hợp đồng. Chúng tôi có ghi lại một số kinh nghiệm thực tế khi thuê outsource phần mềm để bạn tham khảo và tránh những rủi ro thường gặp.
Vài mẹo nhỏ khác đáng để ý
Ngoài các mẹo chính ở trên, đội ngũ còn thường dùng thêm vài thứ nhỏ trong công việc hằng ngày. Đầu tiên là using declaration, cho phép tự động giải phóng tài nguyên như kết nối database hay file stream mà không cần khối lệnh using truyền thống, nhờ đó code gọn hơn hẳn. Tiếp theo là record type cho những đối tượng chỉ chứa dữ liệu, vì record đã có sẵn so sánh theo giá trị và cú pháp khởi tạo ngắn gọn, khác với class thông thường. Cuối cùng là đặt tên biến và phương thức đúng ngữ nghĩa ngay từ đầu, vì phần lớn thời gian ta đọc code để hiểu chứ không phải để viết mới.
Không mẹo nào trong số này quá phức tạp, nhưng cộng dồn lại sẽ làm codebase dễ chịu hơn nhiều khi bảo trì lâu dài. Nếu team bạn cần một đơn vị hỗ trợ rà soát và tối ưu codebase .NET hiện có, bạn có thể xem qua dịch vụ phát triển phần mềm mà chúng tôi đang triển khai.
Lời kết
Theo chúng tôi, mẹo C# ngắn gọn không nên dừng ở việc học thuộc cú pháp mới. Điều quan trọng hơn là hiểu vì sao một cách viết tốt hơn cách cũ, và biết lúc nào nên áp dụng, lúc nào nên giữ cách truyền thống cho dễ hiểu. Hy vọng những chia sẻ từ kinh nghiệm thực chiến này giúp bạn viết C# gọn gàng hơn mỗi ngày. Nếu bạn có mẹo riêng, cứ thử áp dụng vào dự án tiếp theo và xem sự khác biệt thế nào.
