Làm thế nào bạn có thể giải thích mã Code đẹp cho một người không lập trình? [đóng cửa]

Khi nói chuyện với một người bạn không phải lập trình viên, tôi tình cờ đề cập đến khái niệm "mã đẹp" và cô ấy muốn hiểu điều đó có nghĩa là gì, nhưng tôi có chút hụt hẫng khi giải thích nó với người không có Bối cảnh nào.

Khi tất cả các mã trông giống như vô nghĩa với ai đó, làm thế nào bạn có thể giải thích điều gì làm cho một đoạn mã đẹp hơn một đoạn mã khác? Tương tự cũng có thể hữu ích.

Tương tự ngôn ngữ

Hãy nghĩ về câu chuyện yêu thích nhất của bạn. Nó có lẽ được viết rất đẹp. Đối với một người không nói tiếng Anh, chỉ vì họ không thể hiểu nó hoặc hiểu lý do tại sao nó đẹp không làm mất đi vẻ đẹp của nó.

Tương tự xây dựng

Hãy xem xét một ngôi nhà tồi tàn được xây dựng. Nó có cửa ra vào và cửa sổ rõ ràng là gạch. Vữa bị nứt ở một góc nơi nền móng không đủ. Và không ai có thể hiểu tại sao có một cầu thang dẫn lên tầng 2 không tồn tại. Nhà vệ sinh được xây dựng bên cạnh nhà bếp không có quạt hút và nằm ở vị trí mà những cơn gió thịnh hành sẽ thổi bay mùi hôi khó chịu qua phần còn lại của ngôi nhà. Ống khói từ lò sưởi mở cách một số gỗ 5cm, sẵn sàng để bắt lửa.

Ngược lại với một ngôi nhà là nơi cần có, nó được bảo trì thấp, cách nhiệt hoàn hảo để một chút nhiệt mặt trời sẽ giữ ấm trong mùa đông, năng lượng được phục hồi từ thông gió, do đó bạn có cả không khí trong lành, nhiệt độ thoải mái và hóa đơn điện không đáng kể. Nó được chế tạo bằng vật liệu không cháy để không bị cháy. Nó sẽ chịu được trận động đất 9.0 và cơn lốc xoáy F5. Nó chỉ tốn hơn 30% để xây dựng so với ngôi nhà khác, nhưng sẽ trả phần chênh lệch trong 5 năm. Và nó là thẩm mỹ.

GUI giống như hình dáng bên ngoài của một ngôi nhà. Người dùng có thể nhận ra vẻ đẹp trong GUI, giống như họ có thể đánh giá cao một ngôi nhà đẹp. Nhưng có lẽ thậm chí quan trọng hơn, vẻ đẹp thực sự trong thiết kế trong cả nhà và chương trình là những thứ vô hình đối với người không quen biết, nhưng quan trọng hoặc tốt đẹp để có bất kể.

Hãy nghĩ về một chiếc xe hơi.

Hầu hết chúng ta nhìn vào chiếc xe, và chỉ có thể nhìn thấy cơ thể. Nếu ai đó sửa chữa một số dings và đặt một công việc sơn mới trên xe, nó sẽ trông đẹp hơn nhiều. Về cơ bản là cùng một chiếc xe, nhưng đó là tất cả những gì chúng ta thấy.

Một thợ máy mở xe, và nhìn vào động cơ. Họ thấy động cơ đó tốt như thế nào. Họ thấy rằng mọi thứ được sắp xếp để dễ dàng có được, duy trì và làm việc. Họ nhìn thấy các bộ phận và biết nó được thiết kế tốt như thế nào. Đối với một thợ cơ khí có kinh nghiệm, động cơ của một chiếc xe chất lượng cao được bảo trì tốt trở thành một điều tuyệt vời. Họ không thể giải thích cho bạn điều gì làm cho nó đẹp, nhưng quan niệm về cái đẹp của họ có khả năng chuyển thành chi phí bảo trì thấp hơn, tuổi thọ xe dài hơn và hiệu suất tốt hơn. Tất cả những điều này làm tăng giá trị của chiếc xe đó, mặc dù bạn không thể nhìn thấy nó.

Khi bạn nhìn vào một trang web, hoặc một ứng dụng, bạn đang nhìn vào nó giống như hầu hết chúng ta thấy ô tô. Khi tôi nhìn vào mã tôi đang nhìn nó giống như người thợ máy nhìn vào động cơ của chiếc xe. Bạn không bao giờ có thể trải nghiệm vẻ đẹp của mã đó như tôi, nó thực sự vô hình với bạn. Nhưng vẻ đẹp đó quan trọng giống như vẻ đẹp của thợ máy. Nó xác định phần mềm đó chạy tốt như thế nào, loại vấn đề nào sẽ có, phần mềm có thể được cải thiện dễ dàng như thế nào, v.v. Tất cả những điều này làm tăng giá trị của phần mềm đó, mặc dù bạn không thể thấy nó.

Tất cả các mã hiện tại, là bắt buộc, và không có mã nào yêu cầu giải thích.

Tôi muốn nói đến thơ:

Một bài thơ được viết tốt có một cảm giác khác với nó so với một đoạn trích từ một hướng dẫn dịch sai về cùng một chủ đề.

Các vấn đề mã hóa là về khái niệm hóa, vì vậy mã đẹp đại diện cho một khái niệm đáng chú ý của vấn đề.

Ví dụ, chúng tôi thích nó khi một vấn đề có thể được giảm xuống còn một vấn đề giải quyết tồn tại, cho vay cái nhìn sâu sắc vào bản chất của vấn đề riêng của mình .

Đôi khi việc tái khái niệm hóa vấn đề có thể làm cho nó có vẻ dễ dàng; chúng tôi nói về các giải pháp tao nhã đòi hỏi các thủ thuật đơn giản giúp đơn giản hóa một nhiệm vụ khó khăn.

Đối với tôi, Quicksort là một ví dụ đẹp: chọn một phần tử ngẫu nhiên từ một mảng, sau đó so sánh mọi phần tử khác trong mảng với nó; nếu số lượng nhỏ hơn nó, đặt nó vào đống A; nếu số lớn hơn số đó, hãy đặt nó vào đống B. Bây giờ, bằng bất đẳng thức tam giác, không có phần tử nào trong cọc A sẽ không cần phải so sánh với bất kỳ phần tử nào trong cọc B. Tái diễn trên A và B, và bạn đã hoàn thành .

Nhắc nhở tôi về điều này:

Nguồn: XKCD - LISP

Không có mã không tầm thường nào có thể hoàn hảo bởi vì mã hoàn hảo đòi hỏi đồng thời thỏa mãn các mục tiêu thường xung đột. Do đó, mã đẹp sẽ cân bằng tất cả các thuộc tính quan trọng một cách hoàn hảo cho nhiệm vụ trong tay và tiến gần hơn đến việc thỏa mãn tất cả các thuộc tính này đồng thời nhiều nhất có thể nghĩ. Không theo thứ tự đặc biệt:

• Dễ đọc
• Sự đồng tình
• Hiệu quả
• Uyển chuyển
• Nhân chứng
• Mạnh mẽ
• An toàn / chứng minh ngu ngốc
• Hoàn thành
• Tính nhất quán
• Dễ sử dụng (đối với API)

Những bức tranh của Jackson Pollock là một ví dụ về một cái gì đó đẹp đối với một số người và vô nghĩa với những người khác.

Nếu người đó thành thạo toán học, tôi thích so sánh mã đẹp với một giải pháp tao nhã cho một vấn đề.

Một số khía cạnh của mã tốt là:

1. Nó có số lượng lớn các chi tiết nhỏ mà tất cả đều cùng hướng
2. Nó phù hợp trong cấu trúc , mọi phần theo cùng một mẫu
3. nhưng nó không lặp lại , thay vào đó mỗi phần là khác nhau
4. nó cũng không cho phép hành vi được coi là không hợp lệ
5. nó có số lượng nhỏ nhất có thể của các trạng thái khác nhau
6. bạn có thể hiểu toàn bộ hành vi của mã bằng cách đọc các nguyên mẫu hàm
7. nó không có tác dụng phụ
8. việc thực hiện nó được đảm bảo dừng lại
9. nó không sử dụng bất kỳ tính năng nâng cao nào có sẵn trong các ngôn ngữ lập trình
10. nó không quá phức tạp so với sự phức tạp của vấn đề mà nó giải quyết
11. có không có lỗi hoặc hành vi undefined trong nó
12. nó có thể được biên dịch với trình biên dịch từ một số nhà cung cấp khác nhau
13. nó không phụ thuộc vào mã không được sử dụng

Đối với tôi, ngôn ngữ là công cụ của tôi.

Và giống như bất kỳ thợ thủ công nào, tôi thích các công cụ của mình ở trong điều kiện đúc.

Các điều kiện của mã càng tốt, liên quan đến sự rõ ràng của khái niệm, khả năng bảo trì và khả năng đọc. mã càng tốt.

Vì vậy, đối với tôi, đọc mã được viết tốt cũng giống như mở hộp công cụ với các công cụ được chế tạo tốt.

Tôi đã sử dụng sự tương tự này một vài lần với thành công. Đặc biệt là những người có nền tảng thực tế hoặc nghệ thuật hơn dường như hiểu khái niệm mã sạch / đẹp theo cách này.

Tôi nghĩ rằng nó phụ thuộc vào những gì bạn có nghĩa là mã đẹp.

Đối với tôi, mã là đẹp khi nó có thể đọc được. Ngoài các vấn đề có thể xảy ra với các khái niệm lập trình, một giáo dân có thể đọc và, ít nhất là ở mức độ cao, hiểu được mã đang làm gì.

Như một số câu trả lời khác đã thảo luận, mã cũng có thể đẹp theo nghĩa là nó đạt được chức năng phức tạp bằng cách kết hợp một vài khái niệm đơn giản. Không chắc loại tương tự nào là tốt nhất để giải thích điều đó với một người không lập trình, nó phụ thuộc vào giáo dân. Đồ chơi xếp hình xuất hiện trong tâm trí, giống như NeoCube .

Theo ý kiến ​​cá nhân và khiêm tốn của tôi, mã đẹp giống như một cuốn tiểu thuyết hay:

• bạn có thể đọc nó từ đầu đến cuối / bạn không cần phải bỏ qua các trang tương lai của cuốn sách để hiểu trang hiện tại.
• nó không có sự lặp lại không cần thiết / một cuốn sách thật buồn tẻ nếu nó luôn luôn nói những điều tương tự.
• mục đích của mỗi phần là rõ ràng mọi lúc / bạn không cần phải có một cuốn từ điển bên cạnh để đọc một cuốn sách (trừ khi đó là thơ / mã golf xD).
• nó được tổ chức trong các cấu trúc có kích thước và độ phức tạp phải chăng (mô-đun, chức năng, câu lệnh, v.v.), nó không có quá nhiều 'lồng' / chương, đoạn và câu được cân bằng chính xác; nó không sử dụng quá nhiều cấp độ câu phụ, v.v.
• nó dễ chịu cho mắt theo cách thức thẩm mỹ (thụt vào độc đáo, các khối được phân định chính xác, v.v.) / giống như một cuốn sách với cách sắp chữ phù hợp.

Nó giống như một công ty trung bình, nơi mọi người đều biết vai trò của họ, thật dễ dàng để tìm ra ai giỏi về điều gì và không có sự trùng lặp về nỗ lực

Vs

Không gian văn phòng nơi vô địch tầm thường, ba người quản lý không có gì để làm tốt hơn là bạn gặp lỗi về các báo cáo TPS,! @ # $ Ing FAX MÁY KHÔNG BAO GIỜ LÀM VIỆC !!! và bất kỳ nhân viên nào cũng có thể chỉ nhận được khoảng 15 phút làm việc thực tế một tuần. Một nhân viên thậm chí có thể không làm việc kỹ thuật ở đó nữa vì ai đó quên sa thải anh ta (thật khó để nói thực sự vì không ai làm việc hiệu quả và thật khó để đánh giá những gì họ đang cố gắng thực hiện). Và để có được bất cứ điều gì thực tế đòi hỏi phải điều hướng một hệ thống phức tạp quá mức vô lý mà ai đó đọc và nghĩ rằng sẽ trông gọn gàng trong hồ sơ của họ mặc dù nó không thực sự giải quyết vấn đề họ gặp phải.

Không có "mã đẹp", có "thuật toán thanh lịch" và "thiết kế thanh lịch". Thiết kế có thể được hiểu bởi những người không lập trình.

Tôi ghét các lập trình viên tranh luận về "mã đẹp", bởi vì bằng cách này hay cách khác, họ sẽ không thực sự biết người phiên dịch hoặc trình biên dịch sẽ tiêu hóa nó như thế nào và máy sẽ làm gì, vì vậy nó giống như một đứa trẻ chỉ cho mẹ anh ta biết câu chuyện tuyệt vời của anh ấy là, nhưng thực sự, nó không phải.

Bạn có giải thích cho mọi người tại sao một bức tranh đẹp lại đẹp không? Không. Bạn cho họ xem ảnh (bởi vì, bạn biết đấy, một bức tranh nói hơn 1000 từ). Vì vậy, điều tốt nhất là, cho họ thấy một đoạn mã nhỏ thực sự thanh lịch, đẹp đẽ, hoàn hảo (và có thể là so sánh với cách Joe Average đã mã hóa nó).