Bạn có thích sự cụ thể hoặc dễ đọc trong mã của bạn? [đóng cửa]

Phím tắt ngôn ngữ thường có thể được sử dụng để làm cho mã ngắn gọn hơn.

Ví dụ, các toán tử liên kết ternary và null có thể giảm số lượng mã, nhưng có thể gây bất lợi cho khả năng đọc:

Trong C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

có chức năng tương đương với:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

nhưng rõ ràng dài dòng hơn rất nhiều.

Nơi nào bạn vẽ đường khi nói đến sự đồng nhất và dễ đọc?

Cả hai.

Ví dụ đầu tiên của bạn chắc chắn dài dòng hơn và rõ ràng hơn ... nhưng nó cũng yêu cầu tôi quét năm dòng thay vì một dòng. Tồi tệ hơn, nó coi thường mục đích của nó - gán một giá trị cho newGuy.Boss.

Ví dụ thứ hai của bạn có thể khiến tôi mất một giây nếu tôi không quen với toán tử liên kết null, nhưng không có nghi ngờ gì về mục đích của nó và nếu tôi quét qua một thói quen lớn hơn để tìm nguồn giá trị, nó sẽ dễ dàng hơn nhiều cho tôi để chọn ra cái này

Bây giờ, tương phản điều này:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...với:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

Ví dụ sau lại ngắn hơn nhiều, nhưng bây giờ nó che khuất mục đích của nó bằng cách làm cho các tác vụ được kích hoạt bởi cùng một bài kiểm tra dường như là khác biệt. Ở đây, tôi cảm thấy sự dài dòng của trước đây là hợp lý.

Mặc dù cả hai đều là mục tiêu tốt, tôi sẽ luôn bên cạnh Khả năng đọc khi buộc phải chọn một mục tiêu.

Tôi sẽ lập luận rằng ví dụ của bạn cải thiện cả khả năng đọc và ngắn gọn. Tuy nhiên, hãy xem xét:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

như trái ngược với

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

Cái sau ngắn gọn, nhưng khó đọc qua. Cái trước là dài dòng, nhưng dòng logic là rõ ràng.

Cuối cùng, brevity không phục vụ nhiều mục đích, ngoài khả năng phù hợp hơn trên màn hình. Khả năng đọc giúp dễ dàng gỡ lỗi hơn và do đó thường được ưu tiên hơn.

Tôi sẽ nói như một quy tắc chung không bao giờ hy sinh khả năng đọc vì tính đồng nhất, nhưng không bao giờ đánh giá khả năng đọc dựa trên một lập trình viên khác thiếu kiến ​​thức về chủ đề đó.

Sự đồng nhất và dễ đọc không đối nghịch. Giống như câu trả lời này, đôi khi ngắn hơn là dễ đọc hơn.

Tôi sẽ nói rằng tôi thích khả năng đọc hơn, mặc dù điều đó đôi khi có nghĩa là sử dụng mã ngắn gọn. (Tức là ternary cho các điều kiện tương đối đơn giản trong một khối điều kiện lớn hơn.)

Về cơ bản, nếu nó khó hiểu một cách không cần thiết, đừng làm điều đó.

Khả năng đọc đến trước khi nó xung đột với tính đồng nhất, bởi vì mã được sửa đổi thường xuyên hơn so với ban đầu được viết. Mặt khác:

1. Tiếng ồn cú pháp và mã soạn sẵn thường che khuất ý định và do đó làm tổn thương khả năng đọc. Đôi khi mã ngắn gọn hơn cũng dễ đọc hơn. Ví dụ, nghĩ rằng các hàm lambda hoặc các đại biểu / hàm hạng nhất so với các lớp phương thức đơn thực hiện giao diện phương thức đơn.

2. Khả năng đọc nên được đánh giá dựa trên mức độ dễ đọc của một lập trình viên có kinh nghiệm hợp lý, người biết ngôn ngữ và các tính năng độc đáo / nâng cao của nó khá tốt, không phải là một con khỉ mã có khả năng hầu như chỉ biết mẫu số chung thấp nhất.

Một khía cạnh mà tôi không nghĩ đã được đề cập đến: mục tiêu của bạn là gì?

Nếu tất cả những gì bạn quan tâm là bảo mật công việc, hãy tìm sự đơn giản và gọn nhẹ hơn mọi thứ khác. Bỏ qua bình luận mã của bạn, quá.

Nếu bạn muốn có thể dễ dàng trao mã của mình cho người khác trong khi bạn thực hiện một dự án mới thú vị, hãy đọc để dễ đọc, rõ ràng và nhiều bình luận chắc chắn.

_{^{Lưu ý: những điều trên không phải là về cá nhân bạn, @Damovisa; nó cho bất cứ ai lựa chọn giữa hai vị trí.}}

Có một điều mà phiên bản verbose có lợi thế.

Nó có nhiều dòng hơn, và hầu hết các trình sửa lỗi được định hướng theo dòng ! Rất khó để đặt điểm dừng ở giữa một biểu thức, nhưng thường rất đơn giản để đặt nó trong một câu lệnh khối.

Nói cách khác, bạn muốn thấy cái nào trong trình soạn thảo của mình nếu bạn muốn trình gỡ lỗi của bạn khởi động khi boss == nullnào?

(Điều đó nói rằng tôi thích toán tử ?? -

Khả năng đọc nên đến trước, hầu hết mọi người lâu dài dành phần lớn thời gian để sửa đổi hoặc mở rộng mã hiện tại - khả năng đọc là một phần lớn của khả năng bảo trì.

Điều đó nói rằng, sự đồng nhất là một cái gì đó có thể đóng góp cho khả năng đọc. Ví dụ: trong câu hỏi của bạn đoạn trích thứ hai vừa dễ đọc hơn vừa súc tích hơn.