Làm thế nào quan trọng là hướng dẫn định dạng mã? [đóng cửa]

Các tiêu chuẩn mã hóa là phổ biến trong bất kỳ tổ chức phát triển phần mềm nào, nhưng chúng quan trọng như thế nào? Tôi có thể hiểu sự cần thiết của một số tính nhất quán, nhưng khi xử lý những thứ đơn giản như vị trí của niềng răng, chiều dài đường dây, v.v., tôi không chắc các tiêu chuẩn nghiêm ngặt quá mức đóng góp nhiều cho phát triển phần mềm.

Không phải điều quan trọng hơn là mã của bạn có thể đọc được, không phải nó phù hợp với một tiêu chuẩn được xác định trước sao? Dường như họ giống như ... hướng dẫn hơn.

Yêu cầu mọi người tuân thủ 100% theo cùng một hướng dẫn định dạng mã tiêu chuẩn giống như yêu cầu mọi người cộng tác riêng khi viết một bài báo 100 trang với cùng một kiểu viết.

Hy vọng mọi người sẽ viết bài bằng tiếng Anh (hoặc cùng một ngôn ngữ), nhưng các phong cách khác nhau sẽ rõ ràng. Một số sẽ viết nó tốt, những người khác thì không. Một số sẽ sử dụng các cơn co thắt, một số sẽ đánh vần các từ đầy đủ (ví dụ: đó là verus). Vân vân.

Tôi nghĩ bạn đã chạm vào những điểm quan trọng nhất:

1. Đó là một hướng dẫn
2. Dễ đọc

Nếu bạn muốn mã tuân theo cùng định dạng, giống như một tờ giấy có cùng kiểu viết, nó sẽ cần chỉnh sửa và sửa đổi. Mã sẽ cần được làm sạch, xem xét, tái xác nhận, v.v.

Tôi chưa bao giờ ở một cửa hàng nơi tôi hoàn toàn hài lòng với phong cách hoặc định dạng mã hóa của nhà phát triển khác (tối thiểu vì nó không giống như của tôi). Nhưng tôi sẽ hài lòng nếu tôi có thể đọc / hiểu nó và nếu nó phù hợp. Tất cả mọi thứ khác là đường trên cú pháp cú pháp.

Vì vậy, để trả lời câu hỏi của bạn: hơi quan trọng, nhưng chắc chắn đó không phải là ngày tận thế nếu họ không.

Đối với các tiêu chuẩn định dạng, tôi làm theo những gì mọi người đang làm. Nếu họ đang sử dụng PascalCase cho mọi thứ, thì tôi sử dụng PascalCase. Nếu họ sử dụng _camelCase, thì tôi sử dụng _camelCase. Tại sao? Bởi vì nó giới hạn số lượng định dạng lại mà tôi làm và giới hạn những gì người khác phải làm để làm cho nó "trông ổn". Các tiêu chuẩn định dạng thường có để làm mọi thứ dễ dàng cho mọi người.

Ở công việc hiện tại của tôi, một trong những nhiệm vụ đầu tiên của tôi là đưa ra một tiêu chuẩn mã hóa cho nhóm phát triển của chúng tôi.

Nỗ lực đầu tiên của tôi dài khoảng sáu mươi trang (nó được tích hợp nhiều Nguyên tắc khung từ Microsoft). Tôi đã được yêu cầu giảm bớt nó, và nỗ lực tiếp theo của tôi là dài mười trang, sử dụng các ý tưởng từ nhiều nguồn tốt. Tôi đã được yêu cầu giảm nó xuống một lần nữa, và cuối cùng tôi đã giảm xuống còn ba hoặc bốn trang, tôi nghĩ vậy.

Nó không bao giờ được thông qua.

Tại sao? Bởi vì tôi làm việc với rất nhiều người thực sự thông minh, những người đã tuân theo một tiêu chuẩn mã hóa hợp lý theo bản năng.

Về phần mình, tôi làm theo các hướng dẫn được chấp nhận chung từ Microsoft và mô phỏng các kiểu thường được sử dụng của người khác (Javascript và jQuery được định dạng khác với C #, mặc dù cả hai đều là ngôn ngữ kiểu xoăn). Tôi cũng phá vỡ các quy tắc theo thời gian, khi làm như vậy sẽ làm cho mã dễ đọc hơn.

Nếu bạn sử dụng và IDE thực hiện những điều cơ bản cho việc này (ví dụ như Visual Studio), hãy để IDE làm điều đó và mọi thứ dường như vẫn khó nhìn vào bạn sửa đổi miễn là bạn vẫn để IDE làm điều đó hoặc người tiếp theo tự động định dạng nó sẽ giết nó.

Những gì dễ đọc nhất đối với một người sẽ không dành cho tất cả mọi người.

Nếu bạn không sử dụng loại IDE này, hãy lấy một cái. Thậm chí nghĩ về điều này trong hơn 10 phút là lãng phí tài nguyên IMHO.

Tôi nghĩ rằng có một lợi ích không được đề cập trong việc giúp nhanh chóng hiểu mã. Định dạng mã càng giống với một dự án và tất cả các nhà phát triển, thì càng dễ dàng (và tiềm thức hơn) bạn sẽ có thể làm việc với mã.

Tôi đã có các nhà phát triển cơ sở đến với tôi sau khi cố gắng xử lý các lỗi thậm chí đơn giản trong một khoảng thời gian dài. Sau khi dành vài phút để áp dụng định dạng mã của chúng tôi với họ, họ đã nhanh chóng có thể thấy lỗi mà họ đã bỏ lỡ trước đó.

Trong khi khả năng đọc chắc chắn là quan trọng. Nếu các tiêu chuẩn định dạng mã của bạn được cân nhắc kỹ lưỡng và được sử dụng đúng cách, bạn có thể thấy rằng bạn có thể vượt ra ngoài việc chỉ có thể đọc mã và có thể hiểu mã nhanh hơn.

Một bộ hướng dẫn tôi sử dụng khi phát triển hoặc cập nhật các định dạng mã hóa của chúng tôi là Nguyên tắc phân nhóm Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Như một kết quả / ví dụ trực tiếp, định dạng mã của chúng tôi yêu cầu bất kỳ mã khối nào (nếu, chuyển đổi, v.v.) đều có dấu ngoặc mở trên dòng tiếp theo, để nó thẳng hàng với dấu ngoặc đóng:

if(true)
{
}

Với lý do rằng theo Nguyên tắc Đối xứng, tâm trí của bạn sẽ thấy các dấu ngoặc mở và đóng và nhanh chóng có thể nhận biết khối mã một cách tự nhiên.

Bất kể bạn sử dụng ngôn ngữ hoặc công cụ nào, hãy nghĩ ra thứ gì đó. Cấu hình IDE của bạn và kiểm tra tệp cấu hình.

Khi bất cứ ai kiểm tra dự án, họ sẽ sử dụng các kiểu định dạng tương tự. Không quan trọng phong cách là gì, chỉ có điều nó phù hợp. Tôi có sở thích riêng của mình liên quan đến các không gian v. Các tab và dòng niềng răng tiếp tục. Nhưng hơn cả sở thích của riêng tôi, tôi chỉ quan tâm rằng một tệp mã nguồn nhất định đồng ý với chính nó. Nó làm cho nó dễ đọc hơn nhiều so với việc nó là một mớ hỗn độn do cuộc chiến định dạng.

Điều tồi tệ nhất tôi gặp phải cho đến nay là không sử dụng các tiêu chuẩn mã hóa. Và bạn bị cấm làm cho một số khối mã dễ đọc hơn vì nó phá vỡ các công cụ khác ... Bởi vì chúng tôi đang sử dụng các bản vá để áp dụng các thay đổi (yêu cầu sửa lỗi / sửa lỗi -> sửa / thay đổi -> vá -> bản vá được áp dụng bởi người "đáng tin cậy" -> cam kết) bạn có thể nhận được mã nguồn trông khá buồn cười (từ quan điểm dễ đọc). Ít nhất chúng ta không có ai sử dụng hai biến chữ cái (-.

[rant] Điều thú vị nhất là mọi người đều đồng ý rằng chúng ta cần thay đổi điều này. Thậm chí còn có một vài lần thử định dạng lại (tự động trên cam kết), nhưng vì một tùy chọn định dạng bity nhỏ xíu duy nhất bị thiếu - tất cả mọi thứ đã được giải quyết. Cảnh tượng ... [/ rant]

Nguyên tắc giúp cải thiện chất lượng mã:

• theo quan điểm của người viết: nhiều quy tắc nhằm mục đích giảm việc giới thiệu các lỗi. Ví dụ, một quy tắc nêu rõ rằng if()hoặc các for(;;)cấu trúc phải được theo sau bởi một khối chứ không phải là một lệnh đơn lẻ, làm cho ý định của bộ mã hóa ban đầu rõ ràng và giúp các lập trình viên tiếp theo duy trì điều này.

• từ quan điểm của người đọc: mã tuân theo các hướng dẫn đã thống nhất được xem xét hiệu quả hơn so với mã với nhiều kiểu khác nhau. Người xem xét biết rõ hơn với ít nỗ lực hơn để tìm kiếm các lỗi có thể xảy ra.

Không có tiêu chuẩn chung cho những gì một đội nên hoặc không nên làm. Một số đội cần tuân theo các hướng dẫn nghiêm ngặt, một số thì không.

Vấn đề là, bạn nên làm việc cùng nhau như một nhóm và quyết định điều gì là tốt nhất cho nhóm của bạn . Mã phải dễ đọc, bởi vì nó được đọc theo thứ tự độ lớn nhiều lần hơn so với nó được viết. Nếu nhóm của bạn cần hướng dẫn để tạo mã có thể đọc được, hãy tuân theo một tiêu chuẩn mã hóa. Nếu bạn không, đừng.

Tất cả những gì đang được nói, tôi nghĩ rằng hầu hết các đội sẽ được hưởng lợi từ việc đồng ý về một cách tiêu chuẩn để đặt tên biến, hàm và lớp, dấu ngoặc, v.v. Nếu nhóm không thể đồng ý về một điều đơn giản như vậy, làm thế nào họ có thể mong đợi được đến với nhau và đưa ra quyết định thực sự quan trọng? Thêm vào đó, nhóm của bạn sẽ không được tạo thành từ cùng một người mãi mãi - mọi người rời đi, những người mới được tuyển dụng. Những người mới càng dễ dàng tìm kiếm codebase, họ càng có thể đóng góp nhanh hơn cho nhóm mà không làm giảm chất lượng mã.