Có thể làm cho mã dài đại diện cho một tính toán dễ đọc hơn?

9

Các phương thức dài thường được coi là xấu, tuy nhiên trong mã của tôi, tôi có một số phương thức dài khó hiểu (hơn 50 dòng). Tôi gặp khó khăn khi làm cho các phương thức đó dễ đọc hơn vì một câu lệnh bên trong đã dài hơn 50 dòng và câu lệnh đơn khó đọc đó là xây dựng một truy vấn cơ sở dữ liệu bằng ORM để thực hiện một số công việc cụ thể trong đó công việc được thực hiện ghi rõ trên tên phương thức. Lý do là câu lệnh quá dài vì nó tham gia vào nhiều cột, áp dụng nhiều vị trí và chọn nhiều cột riêng biệt để tạo định dạng đầu ra được ghi lại theo yêu cầu.

Là mã khó đọc như vậy được coi là mã xấu? Tương tự, nếu tôi viết mã cho một thuật toán phức tạp dẫn đến mã khó đọc được gói trong một phương thức có tên rõ ràng, mã đó có phải là mã xấu không?

readability

— Michael Tsang
nguồn

Không có cách nào để bạn tham gia truy vấn theo một cách nào đó? Tôi đoán rằng truy vấn này thay đổi tùy thuộc vào những gì đang diễn ra bên trong phương thức tạo ra. Có lẽ bạn có thể chia nó thành các phần nhỏ hơn và xây dựng theo nhiều bước để dễ đọc hơn.

— Zalomon

ORM của bạn có hỗ trợ lượt xem không? Bạn có thể trích xuất một (nhóm) tham gia vào một khung nhìn và sau đó chọn khung nhìn. Ngay cả khi chế độ xem không được sử dụng ở nơi khác, điều đó có thể giúp phá vỡ một câu lệnh SQL lớn

— Caleth

ORM của bạn có hỗ trợ ngôn ngữ truy vấn giống như SQL không? Nếu có, bạn có thể di chuyển truy vấn sang tệp riêng của mình và bật đánh dấu cú pháp IDE cho nó. Trong ứng dụng của bạn tải truy vấn từ tệp. Nếu IDE của bạn không hỗ trợ chính xác ngôn ngữ truy vấn cụ thể đó, bạn có thể hòa hợp với định dạng SQL mặc dù điều đó có thể không hoàn hảo. Tuy nhiên khả năng đọc phần lớn được tăng lên bởi một định dạng tốt. Điều này cũng có lợi ích là dễ dàng sao chép truy vấn vào Scratchpad và thực hiện sửa đổi ở đó.

— SpaceTrucker

17

Bạn đã viết

Là mã khó đọc như vậy được coi là mã xấu

Vì vậy, bạn chắc chắn đồng ý rằng đó là mã khó đọc và nếu khó đọc, rất khó để duy trì và phát triển - vì vậy tôi đoán bạn coi mã là "xấu" bằng các biện pháp của riêng bạn. Tuy nhiên, đôi khi không rõ ràng làm thế nào để cải thiện một cái gì đó như câu lệnh SQL 50 dòng. Các phép tái cấu trúc "phương pháp trích xuất" dễ dàng không hoạt động và có lẽ bạn không biết phải bắt đầu từ đâu để làm cho mã dễ đọc hơn. Đối với những trường hợp này, bạn vẫn có thể thử một hoặc tất cả những điều sau đây

hiển thị mã người khác có kinh nghiệm hơn bạn trong việc làm sạch mã. Nếu bạn không có ai đó trong tổ chức của mình, bạn có thể hỏi, hãy thử codereview.stackexchange
cố gắng google cho vấn đề cụ thể. Ví dụ của bạn, những thứ như "dọn sạch tuyên bố sql dài" có thể là một khởi đầu tốt. Bạn sẽ ngạc nhiên về số lượng bài báo bạn tìm thấy về chủ đề đó, và ngay cả khi bạn không thể tìm thấy một công thức nấu ăn cho trường hợp của bạn, bạn có thể nhận được một số ý tưởng mới
thay vì yêu cầu biện minh cho những điều bạn không thể làm, hãy tập trung vào những điều bạn có thể làm để dọn sạch mã ít nhất một chút, như thêm ngắt dòng thích hợp, thụt lề thích hợp, thêm một số nhận xét giải thích, đưa ra một số biến tốt hơn Tên. Trong quá trình này, không có khả năng, buộc bản thân phải đọc lại các chi tiết của mã, bạn tìm cách tái cấu trúc mã thành các đơn vị nhỏ hơn
thực hành thực hành thực hành. "Mã hóa sạch" không phải là thứ bạn học được trong một ngày, nó trở nên dễ dàng hơn với nhiều kinh nghiệm hơn. Có thể bạn không tìm thấy giải pháp cho vấn đề của mình ngày hôm nay, nhưng khi bạn quay lại mã trong một vài tháng, nó sẽ khác với bạn.

— Bác sĩ Brown
nguồn

Tôi hơi không đồng ý với phần bình luận, nếu có một phần phức tạp của mã phức tạp vì nó không thể khác VÀ không tìm được cách đơn giản hóa nó, các bình luận không thể đưa ra bức tranh lớn về những gì đang được thực hiện. Tài liệu với một số sơ đồ sẽ là cách tốt hơn. Và một bình luận đề cập đến tài liệu bên ngoài nên được để lại. Tất nhiên những tình huống đó phải là đặc biệt bởi vì chúng tôi biết rằng việc duy trì tài liệu bên ngoài hiếm khi được thực hiện, vì vậy càng ít, càng tốt. Đối với phần còn lại, một câu trả lời tốt như mọi khi.

— Walfrat

@Walfrat: ý định của tôi là cung cấp một hướng dẫn chung về quy trình, không chỉ dành riêng cho "50 dòng mã SQL", và không phải là một giải pháp "vượt trội" với tất cả các phương pháp tiếp cận tiềm năng.

— Doc Brown

Tôi biết, tôi chỉ muốn đề xuất rằng nếu một cái gì đó sau khi được xem xét nhiều lần không thể được đơn giản hóa đủ (dù đó là gì), các ý kiến rất có thể sẽ không giúp ích gì cho điều này làm cho điều này trở nên phức tạp vì vậy sẽ cần một tài liệu bên ngoài tối thiểu. Trong trường hợp cụ thể của truy vấn cơ sở dữ liệu, điều này thậm chí còn dễ dàng hơn bằng cách hiển thị một sơ đồ cho thấy mỗi phần của truy vấn tương quan với nhau như thế nào.

— Walfrat

4

Khó đọc không phải là xấu - khó đọc không cần thiết là xấu.

Một số điều chỉ là khó khăn. Trong trường hợp đó, bạn cần hoàn toàn hiểu vấn đề, viết mã và nhận xét nó tốt nhất có thể để nhà phát triển tiếp theo có cơ hội.

Nhưng một số điều chỉ khó khăn vì bạn đã làm cho chúng khó khăn. Nếu vấn đề có thể được đơn giản hóa và dễ dàng hơn, hãy đơn giản hóa nó. Nếu nó khó hiểu nhưng có thể được phân chia hợp lý thành các bài toán con, thì hãy chia nó thành các bài toán con để đơn giản hóa nó.

— gnasher729
nguồn

Chính xác. Cố gắng hết sức để làm cho mã tự ghi lại, sau đó sử dụng các bình luận để điền vào các khoảng trống. (đã chỉnh sửa: Tôi nhận ra sau khi đăng nhận xét của mình rằng OP đã đề cập đến các truy vấn cơ sở dữ liệu ORM, không phải SQL.)

— Kyle A

1

ORM để tạo một báo cáo? Nghiêm túc? Tìm hiểu một số SQL, người đàn ông. Ngôn ngữ thủ tục là khủng khiếp ở loại điều này.

SQL là một ngôn ngữ được thiết kế tốt hơn nhiều để xử lý các phép nối và chọn phức tạp. Và ngay cả khi bạn không thể làm cho SQL trông đẹp mắt, có tất cả các loại công cụ trực quan có sẵn nơi bạn có thể kéo và thả các đối tượng cơ sở dữ liệu trên sơ đồ và SQL sẽ được tạo cho bạn. Chưa kể bạn sẽ có thể điều chỉnh và tối ưu hóa truy vấn, xem kế hoạch truy vấn của nó, lấy nền tảng để đề xuất các tùy chọn lập chỉ mục bổ sung, v.v ... Nó chỉ linh hoạt hơn.

Tôi chắc rằng một số người ở đây sẽ không đồng ý với tôi, nhưng ORM không phù hợp với mục đích báo cáo phức tạp. Nếu có thể, tôi sẽ cân nhắc việc di chuyển khỏi đó và chuyển sang Ngôn ngữ truy vấn có cấu trúc .

— John Wu
nguồn

2

Thành thật mà nói, thực tế bạn không thích ORM hoàn toàn không liên quan đến câu hỏi.

— Doc Brown

Tôi thích ORM tốt. Tôi nói rằng chúng không phải là một công cụ tốt khi mã "tham gia vào nhiều cột, áp dụng nhiều vị trí và chọn nhiều cột riêng biệt để tạo ra một định dạng đầu ra được ghi lại theo yêu cầu", đó là chủ đề của luồng này.

— John Wu

0

Nói chung, khó đọc mã là một ý tưởng tồi ở bất cứ đâu - ngay cả khi bạn là người duy trì duy nhất - tôi đã có một vài lần quay trở lại một số năm mã hoặc thậm chí vài tuần sau đó và cảm thấy khó khăn để quay đầu lại.

Nếu bạn cần thực hiện nhiều trong một truy vấn, hãy thử chia nó thành các dòng với các nhận xét được nhúng:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah)))

Trở thành:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

— Steve Barnes
nguồn

Tôi mơ hồ về ví dụ của bạn. ý kiến nên giải thích tại sao mã giống như vậy. Những gì cần được thể hiện bởi các định danh ...

— Timothy Truckle

@TimothyTruckle Tôi đồng ý rằng các định danh nên xác định rõ chúng là gì nhưng thường thì chúng không rõ ràng trong mã thông thường - trong trường hợp tên trường bản ghi thường không rõ ràng do các ràng buộc lịch sử mà tôi gặp phải trường hợp là tên trường được giới hạn ở 5 ký tự mà tất cả phải là chữ cái ASCII viết hoa & chúng không thể thay đổi do yêu cầu tương thích, ví dụ như với công cụ báo cáo yêu thích của MD.

— Steve Barnes

0

Ngoài câu trả lời tuyệt vời của @ DocBrown, tôi nghĩ rằng đáng để nhận ra rằng không ai viết mã "tốt" mọi lúc. Mã hóa đang tạo ra sự đánh đổi và thường thì tốt hơn là chấp nhận rằng bạn đã viết một cái gì đó sạch sẽ hơn một chút so với bạn muốn và quay lại sau. Tái cấu trúc là quá trình cải thiện mã theo thời gian - và theo kinh nghiệm của tôi, đó là điều tạo nên một cơ sở mã tốt, chứ không phải "lấy nó ngay lần đầu tiên".

Và bạn đánh giá mã ở cấp độ của ứng dụng, chứ không phải cấp độ của các phương thức / dòng mã riêng lẻ. Vì vậy, nếu bạn có một phương thức phức tạp, nhưng nó được đặt tên rõ ràng, tôi không nghĩ bạn có mã "xấu" miễn là phương thức đó được gắn kết.

Đặt tên là vũ khí lớn nhất bạn có để làm cho mã trở nên dễ hiểu - đặt tên cho phương thức của bạn cho phép mọi người đọc mã của bạn bỏ qua phần thân nếu họ cần. Đặt tên cho các biến của bạn, v.v ... theo cách có nghĩa là người đọc có thể thấy những gì họ đại diện mà không cần phải đọc các câu lệnh gán của họ.

Điều tiếp theo là đảm bảo phương thức của bạn thực sự chỉ làm một điều - tác dụng phụ làm cho mã khó hiểu. Vì vậy, nếu phương thức của bạn trả về dữ liệu cho định dạng đầu ra, thì nó cũng không nên cập nhật trạng thái cơ sở dữ liệu của bạn thành "đã in" hoặc bất cứ điều gì.

Phân lớp / thành phần hóa là điều tiếp theo bạn có thể làm - nếu bạn có một loạt các phương thức phức tạp tạo ra kết quả ORM, hãy kết hợp chúng lại với nhau để người đọc mã của bạn có thể cho rằng tất cả chúng đều hoạt động theo cùng một cách, không có tác dụng phụ, v.v.

— Neville Kuyt
nguồn