Công ty của bạn có một tiêu chuẩn mã hóa? [đóng cửa]

Gần đây tôi thấy rằng Microsoft đã phát hành một tài liệu tiêu chuẩn mã hóa ( Tiêu chuẩn mã hóa khung mã tất cả trong một ) và tôi nghĩ rằng ... Công ty mà tôi làm việc không có tiêu chuẩn mã hóa chính thức nào cả. Chỉ có một vài nhà phát triển và chúng tôi đã cùng nhau đủ lâu để phát triển thành các phong cách tương tự và nó không bao giờ là vấn đề.

Công ty bạn làm việc có một tiêu chuẩn mã hóa tài liệu không? Nếu không, tại sao không? Có một tiêu chuẩn làm cho một sự khác biệt? Có đáng để viết một tiêu chuẩn từ đầu hay bạn nên chấp nhận một tiêu chuẩn khác làm tiêu chuẩn của riêng bạn (tức là biến tiêu chuẩn của Microsoft thành của bạn)?

Điều quan trọng đối với một nhóm là có một tiêu chuẩn mã hóa duy nhất cho mỗi ngôn ngữ để tránh một số vấn đề:

• Việc thiếu các tiêu chuẩn có thể làm cho mã của bạn không thể đọc được.
• Sự bất đồng về tiêu chuẩn có thể gây ra các cuộc chiến đăng ký giữa các nhà phát triển.
• Nhìn thấy các tiêu chuẩn khác nhau trong cùng một lớp có thể cực kỳ khó chịu.

Tôi là một fan hâm mộ lớn của những gì chú Bob nói về các tiêu chuẩn:

1. Hãy để chúng phát triển trong vài lần lặp đầu tiên.
2. Hãy để họ là nhóm cụ thể thay vì công ty cụ thể.
3. Đừng viết chúng ra nếu bạn có thể tránh nó. Thay vào đó, hãy để mã là cách các tiêu chuẩn được nắm bắt.
4. Đừng quy định thiết kế tốt. (ví dụ: đừng nói với mọi người không sử dụng goto)
5. Hãy chắc chắn rằng mọi người đều biết rằng tiêu chuẩn là về giao tiếp, và không có gì khác.
6. Sau vài lần lặp đầu tiên, hãy cùng nhóm quyết định.

Tôi nghĩ rằng điều cần thiết là phải có một tiêu chuẩn mã hóa, ngay cả khi tất cả những gì nó nói là "chúng tôi sử dụng thụt 3 không gian và dấu ngoặc mở đi trên dòng tiếp theo." Một vài lợi ích:

• Nó làm cho việc đọc qua toàn bộ cơ sở mã dễ dàng hơn nhiều, vì việc chuyển đổi giữa các kiểu mã hóa giữa các tệp là khó chịu.
• Nó làm cho việc đọc một tệp dễ dàng hơn, vì bất kỳ tệp nào được cập nhật bởi hai nhà phát triển có kiểu xung đột cuối cùng sẽ có xu hướng làm cho các kiểu đó bị lẫn lộn. Đọc qua một tập tin trộn các tab và khoảng trắng (và chỉnh sửa nó sau) là một nỗi đau ở mông.
• Nó giúp các nhà phát triển mới dễ dàng sử dụng phong cách tốt hơn nếu có một tiêu chuẩn rõ ràng, thay vì một tiêu chuẩn ngụ ý.
• Các quy ước đặt tên nhất quán giúp tìm các hàm / biến dễ dàng hơn nhiều. Đó có phải là ArraySort hay Array_Sort hay sortTheArray hay doSortArray hay ...?

Về việc có nên áp dụng một tiêu chuẩn hiện có hay không, nó không thực sự quan trọng - tính nhất quán là điều quan trọng. Nếu các nhà phát triển của bạn có hàng tá phong cách khác nhau, bạn cũng có thể chọn một kiểu hiện có, đã xuất bản. Nếu tất cả các bạn đã phát triển thành một phong cách khá nhất quán, chỉ cần viết nó xuống và sử dụng nó.

Tôi không đồng ý với "chúng tôi là một cửa hàng X" vì vậy chúng tôi định dạng mã của mình bằng tất cả các ngôn ngữ theo cùng một cách.

Cá nhân tôi đã thấy rằng hầu hết các ngôn ngữ có phong cách được chấp nhận khác nhau.

Tôi thực sự không thể đứng khi lập trình viên C viết mã Java với định dạng C. Nó không chỉ trông không giống Java mà còn đánh lừa họ nghĩ rằng họ có thể sử dụng các thực tiễn giống như C khác trong Java.

Tôi nghĩ rằng nếu bạn có một tiêu chuẩn thì nó phải theo ngôn ngữ

Chủ cũ của tôi có một tiêu chuẩn mã hóa. Tôi cũng đang xem xét chính thức làm tài liệu cho chính mình.

Hoặc, như bạn đề xuất, tìm một tiêu chuẩn hiện có và sửa đổi / áp dụng điều đó. Đối với một công ty, tôi chắc chắn sẽ đề nghị họ xem xét các tiêu chuẩn mã hóa hiện có, nhưng tạo / sửa đổi một tiêu chuẩn cho nhu cầu cụ thể của riêng họ. Không nhất thiết phải tạo một cái từ đầu, nhưng cần thận trọng để đảm bảo rằng tiêu chuẩn mã hóa có ý nghĩa đối với loại phần mềm mà công ty tạo ra.

Vâng, có một tiêu chuẩn mã hóa tạo ra sự khác biệt, nhưng nó không phải là viên đạn bạc. Mã dễ đọc hơn vì không có nhiều xung đột kiểu khác nhau và một số lỗi / cạm bẫy phổ biến có thể tránh được. Ngay cả với một tiêu chuẩn, bạn sẽ có một số biến thể trong các kiểu mã hóa, nhưng tính biến đổi đó sẽ bị giảm. Mục tiêu không phải là cố gắng tránh tất cả các biến thể hoặc chuẩn bị cho mọi tình huống có thể. Quá phức tạp, một tiêu chuẩn mã hóa có thể tồi tệ hơn không có gì cả.

Không may măn. Vì vậy, mọi người đều có cách riêng để sử dụng khoảng cách, thụt lề, v.v., mọi thứ đều bị trộn lẫn (theo cách này chúng ta thậm chí không phải sử dụng chức năng "đổ lỗi" để biết ai là tác giả của một dòng mã!)

Nhưng, thậm chí tệ nhất, ai đó viết tên biến và lớp bằng tiếng Ý, một người khác bằng tiếng Anh ...

Tôi luôn thích ứng phong cách của mình với ngôn ngữ, thư viện và khung tôi đang sử dụng, để mã nguồn trông thống nhất và rõ ràng.

Hãy nhớ rằng đây là một tài liệu tiêu chuẩn mã hóa dành riêng cho Khung mã tất cả trong một.

Tôi đã làm việc tại nhiều công ty khác nhau, một số trong đó có một tiêu chuẩn hiện có và một số (hầu hết) tôi đã giúp phát triển tiêu chuẩn. Đối với hầu hết các phần, nếu bạn đang thực hiện phát triển dựa trên .NET (và ngay cả khi bạn không, hầu hết các quy tắc vẫn được áp dụng), bạn nên xem Hướng dẫn thiết kế khung . Mặc dù điều này là cụ thể để viết API đối mặt công khai, hầu hết các hướng dẫn đều áp dụng tốt như nhau cho bất kỳ mã nào.

Mối quan tâm lớn nhất với các tiêu chuẩn mã là giữ cho nó tương đối đơn giản và dễ hiểu. Bạn muốn các nhà phát triển có thể nội tâm hóa các hướng dẫn được trình bày, do đó, cung cấp cho họ tài liệu trên 50 trang là vô ích. Bạn vẫn có thể tạo tài liệu đó nếu bạn muốn cung cấp nền, ví dụ, v.v. nhưng bạn cũng sẽ muốn một cái gì đó sôi nổi với một bộ hướng dẫn bị bắt nạt. Tiêu chuẩn mã hóa của bạn cũng phải là một tài liệu sống linh hoạt, cần thay đổi khi công nghệ thay đổi.

Các cuộc thảo luận về tiêu chuẩn mã hóa đi xuống này:

• Có bạn cần chúng, tính nhất quán và mã sạch là nền tảng của sự phát triển tốt.
• Những gì họ gần như không quan trọng, miễn là mọi người đều tuân theo các tiêu chuẩn giống nhau.
• Đừng viết riêng của bạn, bạn sẽ kết thúc một cuộc thảo luận vô tận và đau đớn. Có rất nhiều ra phổ biến.
• Sử dụng các tiêu chuẩn công cộng (như các tiêu chuẩn trên MSDN ) mang lại cho bạn một bên thứ ba không thể tranh cãi. Nếu bạn muốn tranh luận với họ, hãy tham khảo điểm 2.

Nếu bạn đang phát triển C # trong Visual Studio, thì StyleCop là một viên đạn bạc. Nếu bạn cũng đang sử dụng ReSharper, thì plugin StyleCop cho ReSharper thật tuyệt vời.

Chúng tôi là một cửa hàng blub, vì vậy chúng tôi sử dụng các quy ước lập trình blub.

Bây giờ Paul Graham và bạn bè thông minh hơn chúng ta rất nhiều, nhưng chúng ta lập trình viên, chúng ta đều có thể đọc lẫn nhau, trên thực tế, bất kỳ lập trình viên blub nào cũng có thể đọc mã blub của chúng ta.

Trong thực tế, do thiết kế của blub, bất kỳ lập trình viên blub nào cũng có thể đọc bất kỳ tệp blub nào và hiểu nó, bởi vì blub chưa có hệ thống macro.

Nếu chúng ta lập trình, C hoặc C ++ (tất cả chúng ta đều là đa ngôn ngữ, mặc dù chúng ta lập trình theo kiểu blub), chúng ta sử dụng kiểu chủ yếu là blub cho mã mới hoặc cho công cụ nguồn mở, tiêu chuẩn của dự án chúng ta đang làm việc.

Bạn cần một tiêu chuẩn. Tôi đã thấy các tiêu chuẩn khác nhau ở các góc khác nhau của một ứng dụng có các khách hàng tiềm năng khác nhau mà tất cả đều muốn thực hiện "theo cách của họ". Có lẽ khái niệm "tiêu chuẩn" đã bị hiểu sai. Rất điên rồ. Và, các tiêu chuẩn tồi tệ nhất được tạo ra bởi một người. Không quan trọng người đó là ai, nếu một người một mình phát triển tiêu chuẩn, gần như chắc chắn họ sẽ là người xấu.

Nó có thể giúp mọi người, nó cũng thực sự có thể giúp với các công cụ:

Nếu bạn muốn có thể sử dụng bất kỳ loại định dạng mã tự động nào bạn thực sự cần để chuẩn hóa các quy tắc mà nó sẽ sử dụng, nếu không bạn sẽ liên tục nhận được rất nhiều thay đổi định dạng vô nghĩa làm lộn xộn các khác biệt của bạn.

Các quy tắc mặc định đặt cho các công cụ phân tích tĩnh cũng có thể kiểm tra một kiểu đặt tên cụ thể và có thể dễ dàng hơn tất cả các vòng để tuân theo đó sau đó viết một loạt các quy tắc mới. (trừ khi bạn sẽ tắt hoàn toàn quy tắc)

cuối cùng là tốt để chuẩn hóa bất cứ điều gì cần được tư vấn với ai đó bên ngoài nhóm của bạn. tức là bạn có thể muốn có một thông báo bản quyền tiêu chuẩn trong các tiêu đề của mình vì bạn không muốn chạy mọi tệp mới mà bạn viết qua nhóm pháp lý của công ty và bạn chắc chắn muốn nhận được tên của bất kỳ API công khai nào ngay lần đầu tiên