Mã đẹp là gì? [đóng cửa]


30

Tôi thường đọc rằng các nhà phát triển phải viết mã đẹp, nhưng đối với người mới bắt đầu như tôi vẫn còn mơ hồ về mã đẹp là gì và làm thế nào để bạn nhận ra nó?

Câu hỏi tất yếu là: Làm thế nào để viết mã đẹp và một số thói quen thực tế để cải thiện chất lượng mã của bạn là gì? , những gì tôi nên quan tâm để làm cho mã tôi viết đẹp (và những gì tôi nên học).



4
Nó chỉ là một con số của bài phát biểu. Vẻ đẹp nằm trong mắt của kẻ si tình, và hơn thế nữa, đó là tất cả về sự rõ ràng của các hướng dẫn mà bạn đã đặt trong một tệp văn bản để giải quyết vấn đề, và bạn hoặc bất kỳ ai khác có thể dễ dàng sửa đổi và duy trì nó trong Tương lai. Ngoài ra, mã của bạn còn đẹp hơn bao nhiêu hoàn toàn tùy thuộc vào bạn - thụt lề, cấu trúc mô đun, độ phức tạp, hiệu quả đồng thời với khả năng dễ đọc, quy ước đặt tên, v.v.
bad_keypoint


Câu trả lời:


55

"Vẻ đẹp được mua bằng sự phán xét của mắt".

Điều đó nói rằng, tôi nghĩ rằng hầu hết các lập trình viên sẽ đồng ý rằng mã đẹp thể hiện sự cân bằng giữa sự rõ ràng và minh bạch, sang trọng, hiệu quả và thẩm mỹ.

  • Rõ ràng và minh bạch : Rõ ràng là cách người đọc có thể dễ dàng suy ra những gì mã làm. Mã trong suốt làm những gì nó dường như làm. Nếu mã dường như làm một việc nhưng thực sự làm một việc khác (hoặc một điều gì đó nữa), thì nó không minh bạch - đó là sai lệch.

  • Thanh lịch : có nhiều cách để thực hiện hầu hết các thuật toán, nhưng một số cách thì vụng về trong khi các cách khác thì gọn gàng và duyên dáng. Sự gọn gàng thường làm tăng thêm sự thanh lịch, nhưng sự cô đọng quá mức có thể làm giảm sự rõ ràng.

  • Hiệu quả : tránh sử dụng tài nguyên không cần thiết (như thời gian CPU, bộ nhớ và I / O).

  • Thẩm mỹ : dễ nhìn. Điều này khá chủ quan. Nó chủ yếu đi xuống phong cách. Một xem xét quan trọng là có một phong cách nhất quán . Mã mà thay đổi, ví dụ, phong cách thụt lề giữa chừng, là xấu xí.


11
một lời giải thích hay, +1
koenmetsu

2
Tôi sẽ đưa "Hiệu quả" ra. Mặc dù trong một ý nghĩa nghiêm ngặt, nó là tích cực, bao gồm nó trong danh sách có thể gây hiểu nhầm ở mức tốt nhất. Nó thường là sản phẩm phụ của những người khác và nó phải là mối quan tâm thứ yếu tại thời điểm mã hóa. Lý do chính là, phần lớn, nó chỉ xuất hiện sau khi trình biên dịch đã phát huy tác dụng ma thuật đen tối của nó.
DPM

@Jubbat Thật vậy - đôi khi giải pháp hiệu quả nhất thực sự dẫn đến mã rất xấu. (Ví dụ: chức năng Root Inverse Square Root cổ điển)
Darrel Hoffman

@DarrelHoffman Đúng, mặc dù sự thỏa hiệp đó cũng đúng bởi nhiều biến xác định mã tốt, không chỉ hiệu quả và phần còn lại (có một lời giải thích dài dòng về điều này trong "Hoàn thành mã" - tiếc là tôi không nhớ phần nào trong phần cuốn sách, gần đầu có lẽ-)
DPM

@Jubbat: Tôi đồng ý rằng hiệu quả thường là mối quan tâm thứ yếu, nhưng tôi vẫn nghĩ nó là yếu tố trong phương trình làm đẹp.
Igby Largeeman

20

Đừng để mọi người đánh lừa bạn nghĩ rằng mã đẹp là như sau:

  • thuật toán thông minh
  • tính năng ngôn ngữ lén lút
  • giải quyết vấn đề với số lượng ít nhất các nét chính

Bởi vì nó không phải là. Mã như thế thật dễ thương , và nó chắc chắn đáng để xem qua, nhưng nó không phải là loại mã bạn muốn giải quyết.

Và bạn có biết rằng đa hình tĩnh đệ quy meta ưa thích kế thừa lambdas variatic-- hoặc bất cứ điều gì bạn đã đọc về trực tuyến? Bạn có thể háo hức nhảy vào các thủ thuật sáng tạo và tiện lợi mà không có lý do rõ ràng để sử dụng chúng. Nhưng mã đẩy ranh giới của ngôn ngữ cũng không đẹp.

Họ thật quyến rũ .
Rất nhiều niềm vui, nhưng hãy tự hỏi mình điều này: Tôi có thực sự muốn dành thời gian khám phá giải phẫu của ngôn ngữ này hay tôi muốn làm việc cùng với một ngôn ngữ và xây dựng một cái gì đó đẹp? Rốt cuộc, một ngôn ngữ lập trình chỉ là công cụ để tạo ra.


Vậy mã đẹp là gì?

Mã đẹp = mã duy trì. ĐÓ LÀ NÓ!
ĐÓ LÀ HÌNH THỨC!

Nếu bạn có thể viết một cái gì đó, hãy quay lại với nó một vài tháng sau đó và tiếp tục đạt được tiến bộ về nó, thì thật tuyệt. Nếu một năm sau bạn nhận ra rằng bạn muốn thêm chức năng cũng như điều chỉnh một tính năng hiện có và bạn quản lý để làm điều đó một cách dễ dàng, thì đó là điều tuyệt vời. Nếu người khác có thể bước vào cơ sở mã của bạn và nhanh chóng tìm ra điều gì đang xảy ra bởi vì mọi thứ được tổ chức, họ sẽ có nhiều tóc hơn và cũng rất đẹp.

Vì vậy, câu hỏi thực sự bạn muốn hỏi là: "Làm thế nào để tôi viết mã dễ bảo trì hơn?". Tôi sợ đó là một câu hỏi lớn hơn và nó là một môn học sáng tạo. Chỉ cần viết mã, nhưng lần này đừng tự hỏi liệu nó có thể đẹp hơn không. Tự hỏi nếu bạn có thể làm cho nó dễ bảo trì hơn.


4
để chống lại các vấn đề bạn nêu ra, đó cũng là lời khuyên cho c2.com/cgi/wiki?KillYourDarlings
jk.

4

Tôi đồng ý với điều này là "Mã đẹp" không phải là một thuật ngữ khách quan hay đặc biệt hữu ích. Và chúng ta không nên cố gắng định nghĩa nó.


Các định nghĩa từ điển điển hình của từ "vẻ đẹp" tiếng Anh đi như thế này:

  • "1. sự kết hợp của tất cả các phẩm chất của một người hoặc vật làm thỏa mãn các giác quan và làm hài lòng tâm trí"
  • "1. chất lượng hiện diện trong một người hoặc vật mang lại khoái cảm thẩm mỹ mãnh liệt hoặc sự thỏa mãn sâu sắc cho tâm trí hoặc các giác quan."
  • "1. Chất lượng mang lại niềm vui cho tâm trí hoặc giác quan và được liên kết với các tính chất như sự hài hòa của hình thức hoặc màu sắc, sự xuất sắc của nghệ thuật, tính trung thực và độc đáo."

(Nguồn http://dipedia.com )

Chủ đề chung là "vẻ đẹp" là về những gì đẹp về mặt thẩm mỹ. Điều đó nhất thiếtchủ quan ... như được minh họa bằng câu nói "Vẻ đẹp nằm trong mắt của kẻ si tình".


Chúng ta có thể áp dụng từ "vẻ đẹp" cho mã, và ý nghĩa rõ ràng là mã là "đẹp về mặt thẩm mỹ".

Nhưng sau đó nói rằng "mã đẹp" có một tập các thuộc tính nhất định (như được đề xuất bởi các Câu trả lời khác) là một mâu thuẫn về ý nghĩa rõ ràng của tính thẩm mỹ. Thẩm mỹ là về cách mọi người ... cá nhân ... nhận thức mọi thứ.

Hay nói cách khác, có một điều gì đó đáng trách về ai đó nói với tôi những gì tôi nên nghĩ là đẹp, có thể là ở con người, tác phẩm nghệ thuật hoặc ... mã.

Theo tôi thấy mã đẹp là mã mà tôi nghĩ là đẹp, và đó là nó. Đó là chủ quan và cá nhân, và hãy để nó ở đó.


2

Đây là lời khuyên của tôi.

Xem qua các câu trả lời Làm thế nào bạn có thể giải thích "mã đẹp" cho một người không lập trình? và xem những đặc điểm họ nói để tập trung vào. Sau đó chọn một cuốn sách như Code Complete và đọc nó để tìm hiểu lời khuyên về cách viết mã tốt hơn.

Tại một số điểm, nó sẽ đánh bạn trong khi nhìn vào mã cũ hơn của bạn, "Điều này thật xấu xí." Nó sẽ là một phản ứng thẩm mỹ trực tiếp. Và nhìn vào nó bạn sẽ nhận ra rằng bạn đang xem mã của mình giống như một lập trình viên và có thể thấy sự xấu xí bởi vì bạn biết mã trông đẹp hơn sẽ như thế nào.


1

Chỉ vì bạn thường đọc về mã đẹp không có nghĩa là những người viết về nó có cùng định nghĩa. Đáng buồn thay, đánh giá bằng câu hỏi của bạn, có vẻ như họ thậm chí không bận tâm đến việc xác định nó ngay từ đầu.

Đối với tôi mã đẹp là:

  • Biểu cảm
  • Ngắn gọn

Mã súc tích không biểu cảm có thể khó hiểu và mã biểu cảm không ngắn gọn có xu hướng bị bồng bềnh và tẻ nhạt để đọc, vì vậy bạn cần cả hai.

Tôi sẽ không bao gồm khả năng bảo trì như là một phần của những gì làm cho mã đẹp, bởi vì vẻ đẹp là thứ bạn nhìn thấy / đọc, không phải là thứ bạn hành động. Nhưng một lần nữa, đó là quan điểm cá nhân của tôi.


0

Thuật ngữ mã đẹp là một thuật ngữ rất mơ hồ và trừu tượng. Thật dễ dàng để tìm ra những gì nó đại diện, và ý nghĩa của nó, nhưng nó không bao giờ nên được xem là nhiều hơn một mục tiêu phụ.

Nó nhắc nhở tôi rất nhiều về số liệu bảo hiểm mã. Khi bạn có được số lượng đủ cao, bạn có thể thư giãn và đi vào một cái gì đó khác. Có một codebase với độ bao phủ khoảng 80% là tuyệt vời, không phải chống đạn, nhưng đủ để làm lạnh và làm những việc khác. Có bảo hiểm 40% là khá đáng sợ và nên khuyến khích bạn tăng số đó lên.

Điểm chỉ là phạm vi bảo hiểm mã chỉ thực sự có ý nghĩa nếu số lượng thấp. Vì vậy, đừng để nó thấp. Khi phạm vi bảo hiểm tăng đến một điểm nhất định, hãy chuyển sang một thứ khác.

Tương tự mã đẹp là tuyệt vời. Nếu bạn có mã đẹp, tuyệt vời, hãy chuyển sang thứ khác. Đừng căng thẳng quá nhiều về nó. Bạn sẽ không bao giờ đạt được 100% điểm đó và nếu bạn thấy bạn sẽ tập trung quá nhiều vào những gì nó đọc, hoặc nó trông như thế nào, và không đủ về những gì nó làm, hoặc nó làm như thế nào . Vì vậy, đến một điểm hợp lý và sau đó dừng lại.

Nhưng nếu mã của bạn bị xáo trộn, nếu đó là một mớ hỗn độn mã spaghetti khổng lồ, nếu nó làm bạn đau đớn để mở tệp, nếu bạn không có nhận xét hoặc tài liệu nào, v.v. thì hãy sửa nó. Và làm nó càng sớm càng tốt.

Theo thời gian, cơ sở mã của bạn sẽ sạch hơn, nhìn chung sáng hơn và đẹp hơn và quan trọng hơn là có thể sử dụng được khi bạn tập trung vào làm cho nó ít bị đào thải hơn. Viết mã đẹp không phải là một quá trình một bước.

Không có triết lý ma thuật. 1000 bước nhỏ hơn của nó được thực hiện cùng nhau, tất cả đều phục vụ một mục đích cụ thể không liên quan gì đến việc mã trông đẹp như thế nào. Nhưng, khi bạn phục vụ tất cả chúng cùng nhau, chúng tạo thành mã đẹp như tổng của các bộ phận của nó. Giống như voltron. Hoặc đội trưởng hành tinh.


0

Tôi thực sự đồng ý với các câu trả lời ở đây, nhưng thực hiện một cách tiếp cận ít kỹ thuật hơn, tôi sẽ nói rằng mã đẹp là một biểu hiện của sự rõ ràng của các tác giả về vấn đề trong tay, nó thể hiện thông qua một ngôn ngữ đơn giản và chính xác.

Đối với tôi, nhìn qua mã đẹp giống như nhìn vào một tác phẩm nghệ thuật, nhìn thấy từng chi tiết mới thể hiện ý định của nhà sản xuất, nhưng cũng là cách các phần khác nhau được nhận ra, mỗi câu trả lời cho rất nhiều câu hỏi, và cuối cùng, cuối cùng, làm thế nào sự tồn tại của nó cảm thấy giống như một quy luật tự nhiên mà mọi thứ đều phù hợp đến mức nó chỉ có thể được mô tả bằng những từ ngữ kinh ngạc: tráng lệ, truyền cảm hứng, đẹp đẽ.

Vì vậy, từ quan điểm đó, trong sự nghiệp là một lập trình viên, bạn có thể khám phá ra những mã đẹp mà người khác có thể không hiểu vì họ thiếu kiến ​​thức hoặc có thể không thấy đáng chú ý nữa vì họ đã bị hư hỏng bởi quá nhiều vẻ đẹp;)

Mã đẹp có tất cả các phẩm chất thực dụng như đã đề cập khác, tôi hoàn toàn đồng ý.


0

Tôi có ba tiêu chí:

  • Đơn giản: Ít nhất nó phải là con người có thể đọc được. Ví dụ: bạn có thể viết mã hoạt động tại O (1) cho một giải pháp với hàng tấn dòng, nhưng tôi thích mã hoạt động với 0 (n) giải quyết với vài dòng. Điều này có thể thay đổi cho các tình huống cực đoan nhưng đối với sự đơn giản ban đầu là quan trọng.
  • Tái sử dụng: Mã phải được sử dụng lại, nhưng không được ghi đè. Nếu bạn cần một thao tác, bạn nên xác định nó theo cách mà bạn có thể sử dụng nó nhiều năm sau đó.
  • Sự thụt lề: Có thể đây không phải là vấn đề đối với bạn, nhưng đối với người mới bắt đầu, đây là điều đầu tiên cần được giải quyết.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.