Có bất kỳ lợi ích nào cho nỗi ám ảnh với việc làm cho mã Code trông khá đẹp không?

Đôi khi tôi dành nhiều thời gian (giờ) lố bịch để làm cho mã "trông đẹp". Tôi có nghĩa là làm cho mọi thứ trông đối xứng. Tôi thực sự sẽ nhanh chóng cuộn qua toàn bộ một lớp để xem liệu có thứ gì nhảy ra không trông "đẹp" hay "sạch" không.

Tôi đang lãng phí thời gian của tôi? Có bất kỳ giá trị trong loại hành vi này? Đôi khi chức năng hoặc thiết kế của mã thậm chí sẽ không thay đổi, tôi sẽ chỉ cấu trúc lại để nó trông đẹp hơn.

Tôi chỉ là OCD hoàn toàn hay có một số lợi ích ẩn trong điều này?

Sử dụng một trình định dạng tự động. Nếu bạn thực sự đang dành nhiều thời gian đó để chỉnh sửa mã theo cách thủ công, tôi sẽ sẵn sàng đoán bạn không bị thách thức / buồn chán, bởi vì hoàn toàn không có lý do nào cho nó. Ctrl + K, Cntrl + D trong VS sẽ định dạng toàn bộ tài liệu. Bạn có thể sử dụng một cái gì đó như Style Cop nếu bạn muốn thứ gì đó nặng hơn một chút.

Thật tốt khi có niềm tự hào về mã của bạn, nhưng không phải khi phải trả giá bằng sự thông minh (tìm kiếm giải pháp hiệu quả nhất. Trong trường hợp này, sử dụng một công cụ để tự động hóa một quy trình tẻ nhạt) và hoàn thành công việc (những gì khác có thể bạn đã làm việc trong những giờ đó?).

Nếu bạn không thay đổi bất cứ điều gì cho phép nó được hiểu rõ hơn, thì có, bạn đang lãng phí thời gian của mình.

Không có gì ẩn, mã đẹp dễ đọc và dễ bảo trì.

"Giờ" có vẻ hơi quá mặc dù trừ khi bạn có một cơ sở mã lớn. Không phải mọi thứ phải hoàn hảo, nó chỉ cần phải tốt

Đó là một vấn đề của sự phán xét; nếu bạn đang dành hàng giờ, tôi sẽ nói bạn sẽ vượt lên trên đỉnh. Tuy nhiên, có những thứ mà con người có thể làm mà một công cụ tự động định dạng không thể làm được và những điều bạn có thể làm để làm cho mã của mình dễ đọc hơn, khó nắm bắt trong các tiêu chuẩn mã hóa của công ty.

Chẳng hạn, khi khai báo các biến trong một lớp, tôi muốn có các nhóm logic - nó giúp việc theo logic dễ dàng hơn.

Mã thường được coi là "viết một lần, đọc nhiều", vì vậy làm cho trải nghiệm đọc trở nên dễ chịu là một thói quen tốt - nhưng theo tôi thì bố cục là vấn đề ít hơn nhiều so với các quy ước đặt tên rõ ràng, trừu tượng sạch và chữ ký phương pháp có cấu trúc tốt.

Tôi đã thấy mã được định dạng đẹp gây ra những khoảnh khắc WTF nghiêm trọng vì quá trình suy nghĩ cơ bản là thiếu sót. Nếu bạn có nhiều giờ để chi tiêu, tôi sẽ dành nó cho thiết kế và tái cấu trúc, thay vì bố trí ....

Không, bạn không hoàn toàn là OCD. Lời khen tuyệt vời nhất tôi từng nghe khi là một lập trình viên là "Mã của bạn sạch sẽ đến mức em trai tôi có thể tìm ra nó."

Một ngày nào đó sẽ có người phải hỗ trợ mã của bạn. Mã sạch sẽ dễ dàng hơn nhiều để hỗ trợ. Và một ngày nào đó có thể là bạn. Trong 6 tháng hoặc một năm bạn sẽ không nhớ những gì bạn đã làm. Nhưng nếu nó sạch sẽ và dễ đọc Nó sẽ quay lại nhanh chóng.

Điều đó nói rằng nếu mã là rác, nó không giúp ích gì cho rác đẹp. Nhưng nếu nó được cấu trúc tốt và chỉ có vấn đề về chức năng thì việc cải thiện chức năng sẽ dễ dàng hơn nhiều.

Không - bị ám ảnh với việc làm cho mã trông đẹp là thiếu điểm .

Đây là một số phần của sự khôn ngoan mà tôi thấy hữu ích:

Hỏi tại sao mã cần phải gọn gàng.

Bạn có thể hoặc không thể lãng phí thời gian của bạn tùy thuộc vào định nghĩa của bạn đẹp.

Định lý cơ bản của định dạng nói rằng bố cục hình ảnh tốt cho thấy cấu trúc logic của chương trình. Làm cho mã trông đẹp là đáng giá một cái gì đó, nhưng nó có giá trị ít hơn so với hiển thị cấu trúc của mã. [pg 732, Code Complete 2nd Edition, Steve McConnell]

Nếu bạn sử dụng hệ thống phiên bản đồng thời để theo dõi các thay đổi trong mã - Không trộn các thay đổi định dạng mã với các thay đổi logic / thêm tính năng trong cùng một cam kết.

Nó sẽ làm cho các thay đổi khó phát hiện hơn và sẽ gây ra xung đột hợp nhất không cần thiết nếu các thành viên khác trong nhóm đang chỉnh sửa tệp. Nếu bạn phải thực hiện thay đổi định dạng, hãy kiểm tra xem các thành viên khác trong nhóm không hoạt động trên tệp đó. [Paraphrased, PG 93, Kiểm soát phiên bản thực dụng bằng cách sử dụng Subversion, Phiên bản 2]

Ngoài ra Martin Fowler nói về "đội hai chiếc mũ" và chuyển đổi giữa chúng suốt cả ngày. Một chiếc mũ để thêm các tính năng, một chiếc mũ để tái cấu trúc.

1. Bạn xem xét thêm một tính năng mới (Mũ tính năng)
2. Bạn kiểm tra mã hiện có để hiểu, dọn dẹp khi bạn đi. (Mũ tái cấu trúc)
3. Cam kết thay đổi.
4. Thêm tính năng. (Mũ tính năng) và như vậy ....

[Paraphrased pg 57ish, Tái cấu trúc, Martin Fowler]

Vì vậy, đừng dành hàng giờ để cố gắng làm đẹp toàn bộ cơ sở mã. Chỉ cần chỉnh sửa đủ mã mà bạn cần để thêm tính năng tiếp theo.

Nói tóm lại ... hãy để mỗi đoạn mã ở trạng thái đẹp hơn so với khi bạn mới đến.

Nếu nó hoàn toàn là định dạng, có lẽ bạn nên đầu tư một chút thời gian vào việc dạy một máy in đẹp như thế nào bạn muốn mã của bạn được định dạng. Điều đó hơi tốn kém về phía trước, nhưng tôi tưởng tượng bạn sẽ bù lại bộ hẹn giờ đó trong 2-3 lần sử dụng.

Nếu đó là tái cấu trúc thực tế, có thể không. Về mặt khái niệm, mã sạch có xu hướng dễ dàng sửa đổi hơn về phía trước và việc "luôn sạch" sẽ giảm bớt sự cám dỗ để cho một cái gì đó đi qua chỉ vì có mã khác có mùi xung quanh.

Nó giúp một chút, nhưng nó không đáng để dành nhiều thời gian cho nó. Ngoài ra, hãy đảm bảo rằng các cải tiến của bạn cũng có thêm phạm vi biến, RAII, sao chép / dán mã nhóm, v.v. Nếu bạn làm tất cả điều đó, nó sẽ trở nên dễ dàng hơn 1000 lần khi bạn phải hiểu mã đó làm gì sau một năm.

Bạn nên tạo mã sạch, nhưng không mất nhiều giờ.

Đối với C, có chương trình gnu-thụt gnu-thụt lề , trong nhật thực, có ít nhất một bộ mã hóa cho Java và tôi đoán cũng có các công cụ cho hầu hết các ngôn ngữ khác. Sẽ là một vài lần nhấp để thụt lề một cách chính xác và một vài phút, nếu bạn muốn vi phạm các quy tắc cho các mục đích cụ thể - như tôi làm đối với các câu lệnh chuyển đổi trường hợp ngắn:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

đó là khó để xác định.

Nếu bạn nghĩ rằng một cái gì đó trông sạch sẽ bằng cách lướt qua nó, bạn đang tập trung vào một cái gì đó hời hợt có thể được tự động hóa.

Đọc bài viết kinh điển này về "Làm cho mã sai nhìn sai" và bạn sẽ thấy chính xác lý do tại sao mọi người thường nghĩ thụt lề (có thể được thực hiện tự động) là không đáng kể:

http://www.joelonsoftware.com/articles/Wrong.html

Riêng danh sách này:

OK, cho đến nay tôi đã đề cập đến ba cấp độ thành tích như một lập trình viên:

1. Bạn không biết sạch từ ô uế.

2. Bạn có một ý tưởng hời hợt về sự sạch sẽ, chủ yếu ở mức độ phù hợp với các quy ước mã hóa.

3. Bạn bắt đầu ngửi thấy những gợi ý tinh tế về sự ô uế bên dưới bề mặt và chúng khiến bạn đủ để tiếp cận và sửa mã.

Tuy nhiên, có một cấp độ cao hơn, đó là những gì tôi thực sự muốn nói về:

4 . Bạn cố tình kiến ​​trúc mã của bạn theo cách mà mũi của bạn không sạch sẽ làm cho mã của bạn có nhiều khả năng đúng.

Đây là nghệ thuật thực sự: tạo mã mạnh mẽ bằng cách phát minh ra các quy ước làm cho các lỗi nổi bật trên màn hình.

"Giờ"? Chà, tôi muốn nói câu trả lời của bạn là "và", không phải "hoặc": vâng, bạn là OCD, nhưng có một số lợi ích cho nó.

Có lẽ.

Nó làm cho mã của bạn dễ đọc nhanh hơn? Liệu nó có làm cho việc lướt qua dễ dàng hơn, để tìm ra những điểm dừng và bắt đầu ở đâu, để tìm các hàm, biến, v.v.? Liệu nó làm cho cách mã của bạn hoạt động rõ ràng hơn? Có phải quá trình làm đẹp buộc bạn phải xem lại một số quyết định thiết kế, và cắt tỉa mã chết hoặc giải pháp bóc tách một nửa mà cuối cùng bạn đã từ bỏ? Nếu vậy, nó hoàn toàn có giá trị.

Mặt khác, nếu bạn đã tìm ra một cách hấp dẫn nào đó để thu hút cảm giác thẩm mỹ của riêng bạn mà không thực sự làm cho mã của bạn dễ làm việc hơn, thì ừ, thật lãng phí thời gian.

Đối với tôi, tôi có xu hướng rơi vào kết thúc OCD của điều này - nhưng tôi sẽ không dừng lại. Hành động cung cấp tài liệu cho một lớp hoặc chức năng buộc tôi phải suy nghĩ về cách thức hoạt động của nó - tôi đang viết nó để ai đó không phải là tôi có thể hiểu được. Và nếu tôi thấy mình vấp phải một loạt các cảnh báo và cảnh báo và xin lỗi về lý do tại sao mã hoạt động theo cách đó, thì đó là một cảnh báo khá mạnh mẽ, nó cần thêm một vòng điều chỉnh trước khi tôi tuyên bố xong.

Đầu tiên không có gì sai trong việc làm cho mã của bạn trông đẹp bởi vì cuối cùng bạn muốn tự hào về việc bạn tạo và trình bày / định dạng mã là một phần của điều đó.

Tuy nhiên, tôi sẽ cẩn thận trong việc không định dạng quá mức mã của mình vì lợi ích của đồng nghiệp hoặc nhà phát triển trong tương lai. Đẹp đối với bạn có thể không đẹp với tôi. :)

Bạn nhận ra vấn đề (hành vi bắt buộc) và triệu chứng (định dạng một cách ám ảnh).

Còn nguyên nhân và cách chữa?

• Bạn đang làm việc quá nhiều giờ?
• Bạn đang nản lòng, buồn chán, lo lắng?
• Nhiệm vụ tiếp theo của bạn là gì? Đó có phải là điều bạn không muốn làm không?
• Lần cuối bạn đi nghỉ là khi nào? Khuyến mãi? Công nhận cho một thành tựu?
• Nó có phải là một vấn đề liên quan
• Bạn đang trong một tháng ba chết?

Đôi khi những triệu chứng này là một dấu hiệu đã đến lúc phải thay đổi táo bạo hoặc tiếp tục.

Mặc dù có tiêu đề hạ thấp, cuốn sách của Yourdon có nhiều gợi ý hữu ích và đối với nhiều tổ chức, đang đưa ra một mô tả khá thực tế.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Bạn có vẻ khá sâu sắc và tôi nghĩ bạn có thể biết câu trả lời.

Bây giờ, cho phép bản thân để hành động trên nó.

Thánh bò!
Bạn chưa bao giờ nghe nói về thụt lề?

tiện ích định dạng mã đã tồn tại hơn 20 năm. Nó có rất nhiều tùy chọn để mã của bạn có thể được định dạng theo bất cứ cách nào bạn muốn, tự động.

ermm - nhưng nó chỉ hoạt động trên C và một số chứ không phải tất cả C ++ .... (wtf? tại sao GNU không nâng cấp nó?)