Giữ cho code của bạn luôn nhất quán

Có rất nhiều thứ trong một chương trình có vẻ như không có ý nghĩa. Một số trong những điều đó, tuy nhiên chúng lại gây ra rất nhiều cuộc thảo luận vô nghĩa ví dụ: Tabs vs spaces (miễn là bạn sử dụng 4 khoảng trống) hoặc ngoặc nhọn vs xuống dòng ngoặc nhọn  (miễn là bạn sử dụng ngoặc nhọn). Tôi muốn nói rằng bạn chọn gì không quan trọng, nhưng có một điều quan trọng cần nhớ đó là khi bạn đã đưa ra quyết định, bạn phải nhất quán!

Tại sao lại quan trọng ?

Khi lần đầu tiên tôi nghĩ về việc viết bài này, tôi nghĩ tôi sẽ đưa ra một luận điểm như: Hãy nhìn code. Bạn dành nhiều thời gian đọc code hơn là viết. Vì vậy, khi nói về tính nhất quán, chúng tôi chủ yếu quan tâm đến việc đọc. Hãy tưởng tượng bạn đang đọc một cuốn sách có phông chữ khác nhau trên mỗi trang, sử dụng khoảng cách và dấu phân cách khác nhau hoặc thậm chí cả cách viết cũng thay đổi từng đoạn văn khác. Bạn thấy cuốn sách đó độc đáo không? Bây giờ, lập luận như vậy có thể là chưa vững chắc, nhưng có vẻ như tôi đã thuyết phục các bạn rồi ?

Những ví dụ tôi nêu trên đã làm bạn lung lay chút đỉnh, và bây giờ tôi có thể cố gắng thuyết phục bạn giữ tính nhất quán bằng cách sử dụng một số luận điểm khác:

• Tổng hợp những thay đổi sẽ dễ dàng hơn – bất cứ ai cố gắng giải quyết xung đột SCM sẽ cảm thấy vui vẻ hơn. Một số vấn đề về tính nhất quán khiến bạn tốn nhiều thời gian hơn trong quá trình tổng hợp những thay đổi.
• Dự đoán code hiệu quả hơn – nếu bạn thấy cấu trúc code, có nhiều cơ hội bạn sẽ biết nó là gì, tại sao nó lại ở đó, nơi cần tìm là ở đâu, bởi vì có thể có các code tương tự trong codebase.
• Một số bug có thể dễ dàng phát hiện hoặc tránh – ví dụ đơn giản nhất hoặc là luôn luôn sử dụng ngoặc nhọn hoặc luôn luôn làm cho các dòng code có khoảng cách và các vòng lặp đơn.
• Những người kỳ lạ như tôi thì hạnh phúc hơn – một số người cần mọi thứ để có được sự đối xứng hoàn hảo, có gọn gàng … Nếu không, não của chúng tôi sẽ báo động và ít hiệu quả hơn ?

Thế nào là giữ tính nhất quán ?

Khoảng trắng

Khoảng trắng cho phép bạn sắp xếp code của bạn một cách độc đáo. Cho phép bạn giữ những điều gần giống nhau thì ở gần và tách riêng những cái không liên quan. Quy ước về khoảng trống có thể giúp bạn tiết kiệm rất nhiều thời gian khi hợp nhất, do đó tốt hơn hết hãy bắt đầu với điều này.

Khi nói đến các ví dụ, như đã đề cập, một trong những lựa chọn sẽ là tab hoặc là space. Nếu space, thì bao nhiêu space? Bao nhiêu tab / space để phân biệt một dòng? Nơi để đặt line và bao nhiêu? Bạn nên đặt chúng giữa các trường? Các trường chú thích? Phương thức? Trước và sau khi vòng lặp? Các phần test của bạn? Tôi có thể liệt kê tiếp, nhưng có thể bạn đã nắm được ý chính.

Thứ tự các Member

Thứ tự là một điểm rất quan trọng khác khi hợp nhất như là SCMs bị lạc khi bạn shuffle những thứ trong một source. Nó cũng ảnh hưởng đến khả năng dự đoán code, vì bạn cần biết liệu bạn nên tìm kiếm hoặc từ chối source cho điều mà bạn muốn tìm.

Đối với điều này có hai sự lựa chọn đặc biệt quan trọng:

1. Thứ tự các cấu trúc ngôn ngữ khác nhau chạy trong một class? Rất có thể bạn sẽ chọn một cái gì đó như: hằng số, trường, constructors, phương thức, inner classes.
2. Thứ tự các phương thức nên chạy trong một class là gì? Ở đây tôi mong chờ một cái gì đó giống như thứ tự từ trên xuống

Ngoặc nhọn “{}”

Ngoặc nhọn không phải là một chủ đề nóng trong Java khi nói đến vị trí của chúng trong một dòng code, nhưng chắc chắn sôi động khi nói đến điều kiện và vòng lặp. Một số ý kiến cho rằng luôn luôn sử dụng ngoặc nhọn làm cho bạn an toàn hơn, bởi vì bạn sẽ không bao giờ quên thêm chúng vào một statement hiện có khi mở rộng nó. Còn những người khác cho rằng những statement nên chứa một line code bất kể thế nào và thế nên ngoặc nhọn là không cần thiết. Trong các ngôn ngữ khác, vị trí của ngoặc nhọn trong một line cũng là vấn đề được tranh luận, bởi vì một số ý kiến cho rằng đó là cách để code dễ đọc hơn.

Với tất cả những điều nói trên, quyết định với team của bạn: bạn có nên sử dụng ngoặc nhọn với conditional và loop? Và, nếu cần: nơi để đặt ngoặc nhọn trong một line là ở đâu?

Đặt tên

Đặt tên là việc rất quan trọng trong phát triển phần mềm, tôi đoán không ai nghi ngờ điều đó. Nói chung, chúng tôi cố gắng để tìm “tên tốt”, tuy nhiên có một số điều mà không thể được đánh giá là tốt hơn hoặc tệ hơn. Chúng ta chỉ có thể chấp nhận.

Ví dụ đầu tiên và rất quan trọng là: Bạn nên đặt tên cho sản phẩm test của bạn như thế nào? Tùy thuộc vào ngôn ngữ và framework được sử dụng, có thể có rất nhiều lựa chọn khác nhau. Nói chung, bạn muốn chỉ định các function đang được test, assumed system hoặc object state và expected behavior. Yếu tố quyết định là: như khi đặt tên trong một bức thư? Thường thấy một vài project, chữ viết tắt được sử dụng làm tên, trong khi một số khác thì có chữ cái đầu tiên viết hoa. Và có lẽ một sự khác biệt nữa mà tôi mới gặp: đặt chữ như “Test” trong một cái tên?

Cấu trúc Package

Các modules/component khác nhau trong ứng dụng của bạn có thể có các block xây dựng tương tự ở cấp thấp hơn ví dụ: Các cấu trúc ngữ cảnh, các repository, vv. Giữ cấu trúc package nội bộ của chúng phù hợp với ứng dụng có thể làm cho dự án dễ kiểm duyệt hơn và nhờ đó dễ hiểu hơn, với giá trị một số package chỉ chứa một hoặc hai class bên trong.

Giải pháp cho các vấn đề tương tự

Điểm này ít nhắc đến các quy ước mà chú trọng hơn nữa về cảm giác code. Nói chung, chúng tôi muốn sử dụng các giải pháp tương tự cho các vấn đề tương tự, đặc biệt là bên trong một tệp nguồn duy nhất, ví dụ: Nếu ai đó đang sử dụng Stream để lọc collection, bạn không viết một vòng lặp for với lệnh if trong một số dòng dưới trừ khi bạn có một lý do chính đáng để làm như vậy. Nếu toàn bộ dự án sử dụng chung một library class để build các URL, bạn đừng escapes và concatenation với String chỉ vì bạn biết mỗi cách đó. Nếu dự án sử dụng các assertions của JUnit cho các bài test unit, bạn không thêm AssertJ vào dự án, chỉ vì bạn thích nó. Đây chỉ là một vài ví dụ mà đã làm phiền tôi trong quá khứ, nhưng có thể bạn đã hiểu được.

Tới phiên bạn!

Chỉ với danh sách trên thì chắc chắn là chưa đầy đủ, đó chỉ là những kinh nghiệm tôi đã trải qua. Nếu bạn có bất cứ ý tưởng nào khác để giữ tính nhất quán, vui lòng viết vào khung bình luận, để chúng ta có thể cùng tiến bộ nhé! ?

Techtalk via Tidyjava