Có nên tránh một số cấu trúc lập trình nhất định (và các cấu trúc khác) để bảo trì không?

Question

Tôi đang làm việc trên một dự án phi cá nhân, do đó, nó an toàn để nói rằng các lập trình viên bảo trì sẽ không được tôi, nếu không tôi sẽ không cần phải đặt câu hỏi này. Bây giờ có một số cấu trúc (đại biểu, biểu thức lambda) mà tôi muốn thử trong mã của tôi, không cố ý làm cho mã khó đọc hơn, nhưng vì chúng cho vay chính mình vào tình huống (và ít mã hơn để nhập tốt), và để thực hành sử dụng chúng cũng như kể từ khi tôi mới đến ngôn ngữ. Tuy nhiên, tôi không chắc liệu người lập trình bảo trì có biết mọi cấu trúc hay không, vì nhiều người trong chúng ta không đến từ nền aC#, và tôi không chắc liệu anh ấy có nhiệt tình về lập trình như tôi hay chỉ điều trị hay không. nó giống như một công việc thường ngày. Vì vậy, câu hỏi của tôi là:

• cấu trúc lập trình nhất định nên tránh để cải thiện maintainabilily?

• Nếu câu trả lời cho câu hỏi trên là có, thì đó là tập con của các cấu trúc cần tránh sử dụng?

• Trách nhiệm của người lập trình bảo trì có học được ngôn ngữ đầy đủ không?

Answer 1

Tôi chống lại Least-Common-Mẫu mã hóa. Chúng tôi là những người chuyên nghiệp, một phần của những gì chúng ta nên làm là học những điều mà chúng ta không biết.

Mặt khác, tôi cũng chống lại mã hóa vinh quang. Sử dụng các cấu trúc đơn giản nhất có thể hoàn thành công việc - mã gỡ lỗi gấp hai lần như viết nó, vì vậy bạn chỉ nên viết mã một nửa thông minh như bạn có khả năng!

Answer 2

Tôi nghĩ quy tắc chung của ngón tay cái là đảm bảo mã của bạn có thể đọc được với nhiều nhận xét, đặc biệt là ở những nơi bạn đang làm bất kỳ điều gì không thẳng về phía trước. Tránh các cấu trúc nhất định như đại biểu và biểu thức lambda không phải là cách để đi, nếu được sử dụng chính xác và hợp lý, các tính năng ngôn ngữ như những tính năng này có thể làm giảm độ phức tạp của mã của bạn và làm cho chúng ngắn gọn và biểu cảm hơn. Xét cho cùng, đó là vẻ đẹp của LINQ, phải không? ;-)

Tôi nghĩ bạn nên tập trung vào việc hoàn thành công việc của mình tốt nhất có thể, cho dù các lập trình viên khác có tất cả kiến ​​thức cần thiết để hiểu mã của bạn nằm ngoài tầm kiểm soát của bạn hay không. Nếu lập trình viên bảo trì đó rời đi, và một người khác đến, thì sao? Bạn không nên điều chỉnh mã của mình cho phù hợp với trình lập trình bảo trì, điều chỉnh mã của bạn để phù hợp với vấn đề mà bạn được giao nhiệm vụ giải quyết thay thế.

Answer 3

Tôi nghĩ rằng ngay cả khi bạn đang viết về dự án của riêng bạn, bạn cũng nên gắn bó càng nhiều càng tốt vào các thành ngữ thông dụng/tiêu chuẩn trong bất kỳ ngôn ngữ nào bạn đang sử dụng.

Tôi đã tự mình chạy vào bẫy này - viết một số mã đã làm điều gì đó "thông minh", không ghi lại đầy đủ và giới thiệu một lỗi nghiêm trọng khi tôi quay lại để thay đổi mã một vài tháng sau đó.

Quy tắc chung của tôi - sử dụng "ngôn ngữ cốt lõi" nhiều nhất có thể, và khi bạn phân tách từ đó, hãy ghi lại cách tiếp cận của bạn một cách kỹ lưỡng. Tránh khai thác đường cú pháp để làm cho mã của bạn ngắn hơn trừ khi nó là thành ngữ chuẩn thực sự (ví dụ: thuộc tính trong C#).Khả năng đọc nên tăng tốc độ gõ mỗi lần.

Nếu bạn đang mong đợi các nhà lập trình bảo trì tiếp nhận công việc của bạn, tất cả điều này là đúng gấp đôi. Bạn không thể mong đợi các trình mã bảo trì thành thạo trong nhiều mô hình trong hầu hết các tổ chức. Do đó, nếu bạn bắt đầu sử dụng các cấu trúc lập trình logic/chức năng như lambdas trong mã hướng đối tượng của bạn sau đó nó giống như viết một chương bằng tiếng Đức trong một cuốn sách tiếng Anh. Bạn có thể muốn độc giả của bạn là những người đam mê đa ngôn ngữ, nhưng rất có thể họ không phải là người.

Answer 4

Tôi tin rằng đặc biệt là các biểu thức lambda làm cho mã dễ đọc hơn nếu có. Thay vì có nhiều cho mỗi người với rất nhiều điều kiện - một lambda sạch sẽ gần như có thể được đọc.

Từ kinh nghiệm của tôi những điều làm cho mã khó đọc là thông minh Func chung đối số ... Những thường chỉ đưa ra tw0 + dễ đọc chức năng và thay thế nó với một chung khó đọc.

Vì vậy, điều quan trọng hơn trong sách của tôi là phải có phương pháp có tên tốt hơn là tránh các cấu trúc nhất định. Nhưng đừng lo lắng về việc họ không biết họ - họ nên học họ dù sao đi nữa.