Có phải sự đơn giản luôn cải thiện khả năng đọc?

Gần đây, tôi đang phát triển một bộ tiêu chuẩn mã hóa cho công ty chúng tôi. (Chúng tôi là một nhóm mới phân nhánh sang một ngôn ngữ mới cho công ty.)

Trong dự thảo đầu tiên của mình, tôi đặt mục đích của các tiêu chuẩn mã hóa của chúng tôi là cải thiện Khả năng đọc, Khả năng duy trì, Độ tin cậy và Hiệu suất. (Tôi bỏ qua khả năng ghi, tính di động, chi phí, khả năng tương thích với các tiêu chuẩn trước đó, v.v.)

Một trong những mục tiêu của tôi khi viết tài liệu này là đưa ra ý tưởng về tính đơn giản của mã. Ý tưởng là chỉ nên có một chức năng gọi hoặc hoạt động trên mỗi dòng. Hy vọng của tôi là điều này sẽ tăng khả năng đọc. Đó là một ý tưởng mà tôi đã thực hiện từ ngôn ngữ trước đây của chúng tôi.

Tuy nhiên, tôi đã đặt câu hỏi về giả định đằng sau cú hích này:

Có phải sự đơn giản luôn cải thiện khả năng đọc?

Có trường hợp viết mã đơn giản hơn làm giảm khả năng đọc?

Điều này là hiển nhiên, nhưng bằng cách "đơn giản hơn", tôi không có nghĩa là "dễ viết hơn", nhưng ít thứ đang diễn ra trên mỗi dòng.

"Đơn giản" là một từ được sử dụng quá mức. "Có thể đọc" có thể được định nghĩa một cách có lợi là "đơn giản để hiểu", trong trường hợp tăng (đơn vị đo lường) này theo định nghĩa sẽ tăng khả năng đọc, nhưng tôi không nghĩ đây là ý của bạn. Tôi đã viết về điều này ở nơi khác , nhưng nói chung một cái gì đó có thể được gọi là "đơn giản hơn" bằng cách trừu tượng hơn (trong trường hợp ít khái niệm có thể biểu hiện nhiều hiện tượng hơn) hoặc bằng cách cụ thể hơn (trong trường hợp đó, một khái niệm không đòi hỏi nhiều nền tảng kiến thức để hiểu ở nơi đầu tiên). Tôi cho rằng, tùy theo quan điểm, một khái niệm trừu tượng hơn có thể được gọi đơn giản hơn là một khái niệm cụ thể hơn, hoặc ngược lại . Điều này, mặc dù "trừu tượng" và "

Tôi sẽ sử dụng như một ví dụ về một số mã Haskell mà tôi đã viết cách đây một thời gian. Tôi đã hỏi một câu hỏi về stackoverflow về việc sử dụng danh sách đơn vị để tính toán một bộ đếm trong đó mỗi chữ số có thể có một cơ sở khác nhau. Giải pháp cuối cùng của tôi (không biết nhiều về Haskell) trông giống như:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Một trong những câu trả lời đã giảm điều này thành:

count = mapM (enumFromTo 0)

Cái nào trong số này là "đơn giản" hơn để hiểu (nghĩa là dễ đọc hơn) phụ thuộc hoàn toàn vào việc người đọc cảm thấy thoải mái như thế nào với các hoạt động đơn điệu (trừu tượng) (và, đối với vấn đề đó, mã không có điểm). Một người đọc rất thoải mái với các khái niệm trừu tượng này sẽ thích đọc phiên bản trừu tượng hơn (ngắn), trong khi một người không thoải mái với các hoạt động đó sẽ thích đọc phiên bản cụ thể hơn (dài). Không có câu trả lời về phiên bản nào dễ đọc hơn cho mọi người.

Nếu tiêu chuẩn mã hóa của bạn là về "Khả năng đọc, Khả năng duy trì, Độ tin cậy và Hiệu suất" thì hãy nêu điều đó .

Đừng cố gắng và quy định làm thế nào để đạt được những điều này vì sẽ luôn có những tình huống có một ví dụ phản biện.

Những gì bạn cần phải kê đơn là những thứ sẽ khiến mã bị phá vỡ nếu không được tuân thủ quá. Các đặc điểm phong cách sẽ không phá vỡ mã và phải là đề xuất (miễn là phần lớn nhóm đồng ý rằng Khả năng đọc còn lại là tùy chọn của nhà phát triển (với đánh giá mã để áp lực ngang hàng nhắc nhở mọi người rằng người khác cần đọc mã)) .

Ít "công cụ trên mỗi dòng", đơn giản và dễ đọc không giống nhau. Người ta có thể sử dụng một thuật toán không có giấy tờ khó hiểu vô cùng phức tạp và mã hóa nó bằng 1 câu lệnh trên mỗi dòng thay vì 2, và nó sẽ không trở nên dễ đọc hơn nhiều.

Ít "công cụ trên mỗi dòng" cũng có thể yêu cầu các nhà phát triển cung cấp màn hình lớn rất lớn để thấy các khối mã giờ được trải rộng hơn theo chiều dọc. Hoặc gây căng thẳng mắt từ việc đọc phông chữ nhỏ hơn.

Khả năng đọc là số liệu rất riêng, thường đòi hỏi sự thỏa hiệp giữa một số số liệu dễ đo lường khác. Hạn chế trước tất cả các số liệu khác đó và sự thỏa hiệp không còn có thể trở thành có thể, dẫn đến mã ít đọc hơn.

Luôn luôn? - KHÔNG

Trớ trêu thay, đạt được mức độ đơn giản phù hợp có thể là một công việc phức tạp. Tôi nghĩ rằng chìa khóa là trong chừng mực. Sự đơn giản cũng có thể nằm trong mắt của kẻ si tình, vì vậy nếu bạn thấy mình suy nghĩ quá mức - hãy để nó một mình hoặc quay lại với nó sau.

Cá nhân, khi tôi cố gắng quay lại và đơn giản hóa một cái gì đó mà tôi đã viết, tôi tập trung vào những lĩnh vực mà tôi đã thay đổi suy nghĩ hoặc thử một vài điều để có được những gì tôi muốn. Những khu vực thường có thể được làm mịn. Sau đó, chỉ cần thực hiện một vài lần thông qua mã để làm cho nó dễ đọc hơn mà không cần phát tán ra nhiều thứ đến nỗi bạn đang nhảy khắp nơi để tìm hiểu những gì đang xảy ra trên một bản sửa lỗi.

Nếu tôi đơn giản, tôi có thể viết mã như thế này:

10000000000000000000000000000000000000000000

Nhưng nếu tôi đi để dễ đọc, tôi sẽ thích điều này:

1e43

Mặt khác, 1000dễ đọc và đơn giản hơn nhiều 1e3trừ khi bạn làm việc với các con số trong ký hiệu khoa học mọi lúc.

Đây là một ví dụ thoái hóa của mô hình tổng quát hơn nhiều mà bạn có thể tìm thấy ở hầu hết mọi nơi - xây dựng một cái gì đó từ các khối rất đơn giản có thể nhanh chóng trở nên không thể đọc được / không hiệu quả / xấu theo nhiều cách khác nhau. Mặt khác, việc khái quát hóa và tái sử dụng khó hơn ("wtf là egì ?! Họ có ý định viết 1343?" Ai đó có thể nói), nhưng về lâu dài có thể giúp ích rất nhiều.

Không cần thiết. Nếu bạn có một hoạt động phức tạp, sự phức tạp đó phải đi đâu đó. Giảm số lượng "nội dung" trên một dòng chỉ có nghĩa là nó sẽ chiếm nhiều dòng hơn, điều này thực sự có thể gây bất lợi cho khả năng đọc mã nếu nó làm cho thói quen của bạn quá "cao" để phù hợp với một màn hình.

Rõ ràng + Tiêu chuẩn + Sử dụng lại mã + Nhận xét tốt + Thiết kế tốt có thể cải thiện khả năng đọc .

Sự đơn giản không phải lúc nào cũng nằm trong tay nhà phát triển vì bản chất của thuật toán và sự phức tạp của cấu trúc ứng dụng ngày nay.

Lấy các trang web đơn giản thực hiện các nhiệm vụ đơn giản. Đưa ra một thói quen sắp xếp, không thể đơn giản hóa logic, nhưng bạn có thể làm cho nó rõ ràng hơn bằng các bình luận, sử dụng các tên biến có ý nghĩa, viết nó theo cách có cấu trúc, v.v.

Có phải sự đơn giản luôn cải thiện khả năng đọc?

Không. Tôi đã thấy nhiều trường hợp thực hiện nhiều việc đơn giản trên một dòng ít phức tạp hơn so với việc có nhiều dòng.

Có một sự đánh đổi giữa ít mã hơn và mã đơn giản hơn.

Nói chung, tôi khuyên bạn nên sử dụng mã đơn giản hơn trừ khi bạn chắc chắn thực hiện nó trong ít dòng hơn là tốt hơn. Tôi rất muốn có mã "quá dài dòng" trên mã "quá phức tạp".

"Làm cho mọi thứ đơn giản nhất có thể, nhưng không đơn giản hơn" - Một cách diễn giải thường xuyên của Albert Einstein

Đơn giản cải thiện mọi thứ . Đối với các giá trị khác nhau của sự đơn giản, tất nhiên. Có ít dòng mã hơn không? Có lẽ. Nó có phải là một thực thi nhỏ hơn? Có thể. Đó có phải là điều mà nhóm của bạn cần phải đồng ý? Hoàn toàn đúng .

Có phải sự đơn giản luôn cải thiện khả năng đọc? Vâng. Là một tuyên bố trên mỗi dòng luôn đơn giản hơn? Không. Khá nhiều ngôn ngữ có toán tử ternary, một khi đã nắm bắt được, nó đơn giản và dễ hiểu hơn so với các phép gán if / other tương đương.

Trong các ngôn ngữ cho phép đặt nhiều biến trên một dòng, làm như vậy thường đơn giản và dễ hiểu hơn bất cứ thứ gì tương đương.

Một ví dụ khác: các biểu thức chính quy làm rất nhiều, thường chỉ trong một dòng và tương đương không có biểu thức chính quy thường khó đọc hơn nhiều . / \ d {3} [-] \ d {3} - \ d {4} / tương đương với một lệnh gọi hàm với ít nhất một số nhận xét và dễ hiểu hơn thân hàm tương ứng.

Dễ đọc và đơn giản là các thuật ngữ chủ quan, tùy thuộc vào con người và bối cảnh, thông thường nhưng không phải lúc nào cũng đi cùng nhau.

Một thuật ngữ khách quan hơn là sự đồng nhất - về nguyên tắc bạn có thể đếm bằng cách đếm các ký tự, mặc dù có một số sai sót trong đó. Sự đồng nhất dường như ngụ ý sự đơn giản và dễ đọc, nhưng có (ít nhất là theo ý kiến ​​của tôi).

Một đoạn mã dài hơn (và có thể phức tạp hơn) có thể dễ đọc hơn nếu nó thể hiện tốt hơn ý định. Cho dù định nghĩa của bạn về sự đơn giản quan tâm đến ý định là một điều chủ quan khác - bạn có thể định nghĩa sự phức tạp về mặt cấu trúc cú pháp và entropy lý thuyết thông tin, chẳng hạn, không liên quan đến ý định nào cả.

Vì vậy, một tên biến dài hơn được chọn tốt có thể ...

• Cải thiện khả năng đọc bằng cách thể hiện tốt hơn ý định
• Giảm sự đồng nhất - nó dài hơn, sau tất cả
• Hoàn toàn không ảnh hưởng đến tính đơn giản cú pháp - cấu trúc cú pháp của mã không thay đổi

Tương tự, tôi có thể viết if (some_boolean == true). So với giải pháp thay thế tương đương if (some_boolean), ...

• Giảm sự đồng nhất
• Giảm tính đơn giản cú pháp, nhưng
• Có thể cải thiện khả năng đọc bằng cách thể hiện tốt hơn ý định.

Tất nhiên điều này sẽ gây ra một cuộc biểu tình rầm rộ - với nhiều người, điều này luôn gây thiệt hại cho khả năng đọc. Đối với tôi, nó phụ thuộc rất nhiều vào nguồn của boolean - ví dụ tên biến (hoặc tên phương thức hoặc bất cứ thứ gì) có thể không thể hiện rõ ràng rằng giá trị là "giá trị thật". Chắc chắn, ifcho bạn biết một cái gì đó, nhưng nó vẫn có mùi. Nhưng nhiều người sẽ gọi tôi là thằng ngốc vì tin vào điều này.

Đó là bằng chứng thêm về tính chủ quan tổng thể, tất nhiên.

Tất cả các bạn đang thiếu một số định nghĩa cơ bản . Đơn giản, từ gốc sim-plex , có nghĩa là một lần . Đơn giản có nghĩa là làm một việc . Dễ dàng, từ gốc dễ dàng , có nghĩa là nằm gần . Dễ dàng có nghĩa là nó ở gần tầm tay . Các ví dụ về mã đơn giản được đưa ra trong các câu trả lời khác không chính xác những gì chúng xuất hiện.

Hãy hiển thị giá trị rất lớn của rotsor . Ông nói điều này thật đơn giản . Không, trong ước tính của tôi, đơn giản. Dễ thôi. Nó ở gần để nhập số 0 yêu cầu.

10000000000000000000000000000000000000000000

Các thể đọc được phiên bản rất đơn giản. Nó làm một điều. Nó biểu thị số bằng cách mô tả kích thước của nó trong một mục đích ký hiệu được xây dựng cho chức năng này.

1e43

Bạn có thể mô tả đoạn mã "đơn giản" của Aidan là làm một việc không? Nó chứa 10 dòng mã (không tính bình luận) và ít nhất 7 khối (như tôi đã đếm chúng). Nếu bạn theo dõi các bình luận, bạn sẽ thấy rằng nó thực hiện ít nhất 4 điều!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Nhưng, một trong những khuyến nghị để viết lại mã này là một tuyên bố. Aidan tuyên bố rằng một người đọc sẽ phải hoặc trở nên quen thuộc với các câu lệnh đơn âm, mã miễn phí con trỏ, v.v ... Điều đó tốt. Những khái niệm này là số ít và độc lập để tìm hiểu.

count = mapM (enumFromTo 0)

Bạn sẽ thấy rằng mã thực sự đơn giản dễ đọc hơn mã dễ dàng bởi vì nó chỉ làm một điều. Bạn có thể cần phải tắt và tìm hiểu thêm "một điều" để hiểu mã đơn giản. Nhưng nó phải luôn luôn dễ đọc hơn.

Có phải sự đơn giản luôn cải thiện khả năng đọc?

Tôi có thể nói, có thể với một chút tranh cãi, hoàn toàn không .

Bạn có thể đưa cho tôi một lớp học với 200 chức năng thành viên trong giao diện công cộng của nó và nó có thể là giao diện công cộng dễ đọc nhất ở ngoài kia. Nó có thể là một niềm vui chỉ tình cờ đọc qua mã như vậy và tài liệu của nó. Tuy nhiên, tôi sẽ không gọi nó là "đơn giản", vì mặc dù dễ đọc, tôi sẽ phải quan tâm đến việc tất cả các chức năng này tương tác với nhau như thế nào, và có khả năng coi chừng các trường hợp khó khăn do sử dụng sai.

Tôi thích một lớp có 20 hàm thành viên không dễ đọc đến 200, vì "khả năng đọc" không phải là ưu tiên hàng đầu đối với tôi trong việc ngăn ngừa lỗi của con người và cải thiện khả năng duy trì mã (dễ dàng trong đó chúng ta có thể thay đổi nó, tức là).

Tuy nhiên, đây là tất cả sẽ xoay quanh định nghĩa cá nhân của chúng tôi về "sự đơn giản". "Độ khó" thường không thay đổi đó một cách hoang dại giữa chúng ta, trừ khi ai đó đã mua rất nhiều kinh nghiệm và thành thạo mà họ xem xét regex là rất "dễ đọc", ví dụ như, quên phần còn lại của chúng tôi chỉ mortals.

Sự đơn giản

Có một thời gian, từ lâu, nơi tôi nghĩ "đơn giản" có nghĩa là "dễ đọc nhất có thể". Vì vậy, tôi sẽ viết mã C với rất nhiều chức năng tiện lợi, cố gắng cải thiện cú pháp và làm cho mọi thứ dễ đọc và viết nhất có thể.

Kết quả là tôi đã thiết kế các thư viện cấp cao, phong phú, rất phong phú, cố gắng mô hình hóa một chức năng cho mọi suy nghĩ tự nhiên của con người: người trợ giúp khi người trợ giúp, tất cả để định hình mã khách hàng thành cú pháp dễ đọc hơn. Mã tôi đã viết lại sau đó có thể là "dễ đọc" nhất, nhưng nó cũng là "không thể nhầm lẫn" và "phức tạp" nhất.

Lisp

Tuy nhiên, tôi đã có một niềm đam mê ngắn với LISP vào khoảng giữa những năm 90 (latecomer). Nó thay đổi toàn bộ ý tưởng của tôi về "sự đơn giản".

LISP không phải là ngôn ngữ dễ đọc nhất. Hy vọng rằng không ai nghĩ rằng trích xuất CDR và ​​CAR trong khi gọi hàm đệ quy với một khối dấu ngoặc đơn lồng nhau là rất "dễ đọc".

Tuy nhiên, sau khi vật lộn để khiến bộ não của tôi xoay quanh cú pháp kỳ quặc của ngôn ngữ và cách thức hoàn toàn đệ quy, nó đã thay đổi vĩnh viễn ý tưởng về sự đơn giản của tôi.

Điều tôi tìm thấy với mã tôi đã viết trong LISP là tôi không còn mắc lỗi tinh vi nữa, mặc dù sự khó khăn trong suy nghĩ theo cách đó đã khiến tôi mắc nhiều lỗi trắng trợn hơn (nhưng chúng rất dễ phát hiện và sửa chữa). Tôi đã không hiểu những gì một chức năng đang làm và bỏ lỡ một tác dụng phụ tinh tế, không lường trước được. Tôi chỉ có một thời gian dễ dàng hơn trong việc thay đổi và viết chương trình chính xác.

Sau LISP, sự đơn giản đối với tôi trở thành về sự tối giản, tính đối xứng, tính linh hoạt, ít tác dụng phụ hơn, ít chức năng hơn nhưng linh hoạt hơn kết hợp với nhau theo nhiều cách khác nhau.

Tôi đã đánh giá cao suy nghĩ rằng mã đáng tin cậy nhất là mã không tồn tại. Mặc dù nó chỉ là một số liệu thô, tôi có xu hướng thấy tiềm năng không đáng tin cậy của mã dựa trên số lượng của nó. Tìm kiếm sự thuận tiện cú pháp tối đa và khả năng đọc có xu hướng tăng số lượng đó bằng một yếu tố lớn.

Chủ nghĩa tối giản

Với tư duy LISP được nhúng trong tôi, tôi đã thích các API tối giản hơn. Tôi thích một thư viện có ít chức năng hơn nhưng đáng tin cậy hơn, linh hoạt hơn, ít tiện lợi hơn và tiềm năng khó đọc hơn thư viện cung cấp một lượng lớn người trợ giúp "thuận tiện" và điều đó có thể giúp mã dễ "đọc" nhưng có khả năng bị vấp nhiều vấn đề hơn với sự không đáng tin cậy và bất ngờ xuất phát từ việc hiểu sai những gì một trong số hàng ngàn chức năng này làm.

An toàn

Một điều khác về LISP là sự an toàn. Nó phát huy tác dụng phụ tối thiểu và các chức năng thuần túy, và đó là nơi tôi không còn thấy mình mắc lỗi tinh vi, mặc dù khó đọc và viết bằng ngôn ngữ đã tăng thêm những lỗi trắng trợn hơn tôi có thể nhận ra 10 giây sau.

Các hàm thuần túy và trạng thái bất biến trở nên thích hợp hơn với tôi bất cứ khi nào tôi có thể mua được, ngay cả khi cú pháp của:

sword = sharpen(sword)

... Là một chút ít đơn giản và tách rời khỏi suy nghĩ của con người hơn:

sharpen(sword)

Khả năng đọc VS. Sự đơn giản

Một lần nữa, LISP không phải là ngôn ngữ "dễ đọc" nhất. Nó có thể gói rất nhiều logic vào một phần nhỏ của mã (có thể nhiều hơn một suy nghĩ của con người trên mỗi dòng). Tôi có xu hướng lý tưởng thích một suy nghĩ của con người trên mỗi dòng cho "khả năng đọc", nhưng nó không nhất thiết là "đơn giản".

Với định nghĩa "đơn giản" này, đôi khi "đơn giản" thực sự có thể phần nào cạnh tranh với "có thể đọc được". Điều này đang xem xét mọi thứ nhiều hơn từ quan điểm thiết kế giao diện.

Một giao diện đơn giản có nghĩa là bạn cần học ít thứ hơn để sử dụng nó, và có khả năng có độ tin cậy cao hơn và ít vấn đề hơn do sự tối giản của nó. Một tài liệu toàn diện về chủ đề này có thể phù hợp với một cuốn sách nhỏ hơn là một khối lượng sách khổng lồ. Tuy nhiên, nó có thể yêu cầu một số công việc nặng nề hơn và mang lại mã ít đọc hơn.

"Đơn giản" đối với tôi cải thiện khả năng hiểu chức năng trong hệ thống của chúng tôi ở mức độ rộng. "Có thể đọc được" đối với tôi cải thiện khả năng kết nối từng dòng mã nhỏ với ngôn ngữ tự nhiên và suy nghĩ và có thể tăng tốc độ hiểu biết của chúng tôi về một dòng mã, đặc biệt là nếu chúng tôi không thông thạo ngôn ngữ.

Regex là một ví dụ về những gì tôi cho là "cực kỳ đơn giản". Đó là "quá đơn giản và quá khó đọc" cho sở thích cá nhân của tôi. Có một hành động cân bằng giữa tôi giữa các thái cực này, nhưng regex có chất lượng đơn giản giống như LISP như tôi định nghĩa: tối giản, đối xứng, linh hoạt đáng tin cậy, đáng tin cậy, v.v. Vấn đề đối với tôi với regex là nó quá đơn giản đã trở nên khó đọc đến mức tôi không nghĩ mình sẽ trở nên thông thạo nó (bộ não của tôi không hoạt động theo cách đó và tôi ghen tị với những người có thể viết mã regex trôi chảy).

Vì vậy, dù sao, đó là định nghĩa của tôi về "đơn giản", và nó hoàn toàn độc lập với "khả năng đọc" và đôi khi thậm chí có thể can thiệp vào cái khác, dẫn đến một hành động cân bằng giữa một thư viện "thuận tiện hơn về mặt cú pháp" và dễ đọc hơn hoặc "về mặt cú pháp" bất tiện ", thư viện ít đọc hơn nhưng nhỏ hơn. Tôi luôn luôn tìm thấy các ưu tiên "tiện lợi của sự hiểu biết" và "khả năng duy trì" thực sự để phù hợp với điều kiện sau, với sự ưu tiên mạnh mẽ đối với chủ nghĩa tối giản thậm chí với một số chi phí dễ đọc và cú pháp tự nhiên hơn (nhưng không đến mức regex) . YMMV.

Luôn luôn? - VÂNG

Đạt được mức độ đơn giản phù hợp là một công việc phức tạp và khó khăn. Nhưng luôn luôn có giá trị vì nó luôn cải thiện khả năng đọc. Tôi nghĩ rằng chìa khóa là sự hiểu biết sâu sắc. Tính đơn giản là tuyệt đối, được đo bằng "khái niệm mới" trên mỗi "đoạn" mã. Một vài khái niệm mới có nghĩa là đơn giản hơn.

Tập trung vào các khu vực có một cụm các khái niệm dày đặc và tìm cách "chunk" hoặc "tóm tắt" hoặc "trừu tượng". Thực hiện một vài lần thông qua mã để làm cho nó đơn giản và dễ đọc hơn.

Một sự trừu tượng tốt có giá trị của nó bằng vàng. Một sự trừu tượng tốt làm cho điều này đơn giản hơn - và do đó dễ đọc hơn.

Các câu hỏi nhắc nhở tôi về câu trả lời này trên Stack Overflow, đặc biệt là trích dẫn này (chất lượng thay thế bằng sự đơn giản):

Chất lượng - bạn biết nó là gì, nhưng bạn không biết nó là gì. Nhưng đó là mâu thuẫn. Nhưng một số thứ tốt hơn những thứ khác, nghĩa là chúng có chất lượng hơn. Nhưng khi bạn cố gắng nói chất lượng là gì, ngoài những thứ có nó, tất cả đều gặp sự cố! Không có gì để nói. Nhưng nếu bạn không thể nói Chất lượng là gì, làm sao bạn biết nó là gì hoặc làm thế nào để bạn biết rằng nó thậm chí còn tồn tại? Nếu không ai biết nó là gì, thì với tất cả các mục đích thực tế, nó hoàn toàn không tồn tại. Nhưng đối với tất cả các mục đích thực tế, nó thực sự tồn tại. Những gì khác là các lớp dựa trên? Tại sao người khác lại trả vận may cho một số thứ và ném những thứ khác vào đống rác? Rõ ràng một số thứ tốt hơn những thứ khác - nhưng '`tốt hơn' 'là gì? - Vì vậy, tròn và vòng bạn đi, quay bánh xe tinh thần và không nơi nào tìm thấy bất cứ nơi nào để có được lực kéo. Chất lượng là gì? Nó là gì?

Tôi nghĩ rằng điều quan trọng là bạn phải nhớ rằng một tiêu chuẩn mã hóa được mã hóa cho tất cả các lợi ích của nó sẽ không làm cho các lập trình viên giỏi thoát khỏi những điều xấu. Một từ như 'đơn giản' có thể được giải thích khác nhau bởi những người khác nhau (xem câu trả lời của Aidan Cully), nhưng đó có thể không phải là một điều tồi tệ. Các lập trình viên trẻ sẽ vẫn cần phải xem xét mã của họ bởi các lập trình viên cao cấp và tìm hiểu lý do tại sao các lập trình viên cao cấp giải thích 'đơn giản' lại tốt hơn mã của họ.

Một cuộc gọi chức năng trên mỗi dòng là đơn giản hơn? Hãy thử một ví dụ!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Bạn nghĩ sao? Là một cuộc gọi trên mỗi dòng thực sự đơn giản hơn?