Đối với hầu hết các phần này là sở thích cá nhân, tuy nhiên có một số điều cần xem xét.
Lỗi có thể
Trong khi nó có thể lập luận rằng lỗi do quên add-in niềng răng là rất hiếm, từ những gì tôi đã nhìn thấy rằng họ làm xảy ra thỉnh thoảng (không quên nổi tiếng goto IOS không lỗi). Vì vậy, tôi nghĩ rằng đây phải là một yếu tố khi xem xét phong cách mã của bạn (một số công cụ cảnh báo về sự thụt lề sai lệch , vì vậy nó cũng phụ thuộc vào chuỗi công cụ của bạn) .
Mã hợp lệ (đọc giống như nó có thể là một lỗi)
Ngay cả khi giả định rằng dự án của bạn không gặp phải các lỗi như vậy, khi đọc mã, bạn có thể thấy một số khối mã trông giống như chúng có thể là lỗi - nhưng không, thực hiện một số chu kỳ tinh thần của bạn.
Chúng tôi bắt đầu với:
if (foo)
bar();
Một nhà phát triển thêm một nhận xét hữu ích.
if (foo)
// At this point we know foo is valid.
bar();
Sau đó, một nhà phát triển mở rộng về nó.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Hoặc thêm một khối lồng nhau:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Hoặc sử dụng macro:
if (foo)
SOME_MACRO();
"... Vì các macro có thể xác định nhiều dòng mã, macro có sử dụng do {...} while (0)cho nhiều dòng không? Có phải vì nó nằm trong hướng dẫn kiểu của chúng tôi nhưng tôi nên kiểm tra tốt hơn trong trường hợp!"
Các ví dụ trên đều là mã hợp lệ, tuy nhiên càng nhiều nội dung trong khối mã, bạn càng cần phải đọc để đảm bảo không có bất kỳ lỗi nào.
Có thể kiểu mã của bạn xác định rằng các khối nhiều dòng yêu cầu một dấu ngoặc (không có vấn đề gì, ngay cả khi chúng không phải là mã) , nhưng tôi đã thấy các loại nhận xét này được thêm vào trong mã sản xuất. Khi bạn đọc nó, có một số nghi ngờ nhỏ rằng bất kỳ ai sửa lần cuối những dòng đó đều quên thêm dấu ngoặc, đôi khi tôi cảm thấy cần phải kiểm tra lại có hoạt động như dự định không (đặc biệt là khi điều tra một lỗi trong khu vực của mã này) .
Tiếng ồn khác
Một lý do thực tế để sử dụng niềng răng cho các đường đơn là để giảm nhiễu khác nhau .
Đó là, thay đổi:
if (foo)
bar();
Đến:
if (foo) {
bar();
baz();
}
... Làm cho dòng điều kiện hiển thị trong một khác biệt khi được thay đổi, điều này thêm một số chi phí nhỏ nhưng không cần thiết.
- các dòng hiển thị như được thay đổi trong đánh giá mã, nếu các công cụ phân biệt của bạn dựa trên từ bạn có thể dễ dàng thấy rằng chỉ có niềng răng thay đổi, nhưng sẽ mất nhiều thời gian hơn để kiểm tra nếu dòng đó không thay đổi.
Phải nói rằng, không phải tất cả các công cụ đều hỗ trợ diffing dựa trên từ, diff (svn, git, hg ... vv) sẽ hiển thị như thể toàn bộ dòng thay đổi, ngay cả với các công cụ ưa thích, đôi khi bạn có thể cần phải nhanh chóng nhìn qua một dòng đơn giản dựa trên diff để xem những gì đã thay đổi.
- các công cụ chú thích (chẳng hạn như
git blame) sẽ hiển thị dòng đang được thay đổi, làm cho việc theo dõi nguồn gốc của một dòng nhiều bước hơn để tìm ra thay đổi thực sự.
Cả hai đều nhỏ và phụ thuộc vào thời gian bạn xem xét mã hoặc theo dõi xuống mà cam kết thay đổi dòng mã.
Một sự bất tiện hữu hình hơn khi có thêm các dòng thay đổi trong một khác biệt, khả năng thay đổi mã cao hơn của chúng sẽ gây ra xung đột khi hợp nhất và cần được giải quyết thủ công .
Có một ngoại lệ cho điều này, đối với các cơ sở mã có {trên dòng riêng - đó không phải là vấn đề.
Đối số nhiễu khác không giữ nếu bạn viết theo kiểu này:
if (foo)
{
bar();
baz();
}
Tuy nhiên đây không phải là một quy ước chung, vì vậy chủ yếu thêm vào câu trả lời cho đầy đủ (không đề xuất các dự án nên sử dụng phong cách này) .
