Có cách nào để hỗ trợ các kiểu mã hóa khác nhau trong một nhóm phát triển không

Vấn đề: Hai nhà phát triển => ba ý kiến ​​về sự cố định, niềng răng trên dòng mới hay không, v.v.

Chúng tôi thường làm việc với ba hoặc bốn người trong các dự án của chúng tôi và mỗi người trong số họ có phong cách mã riêng. Tôi biết, giải pháp chung là đồng ý về kiểu mã, mọi người đều phải sử dụng, nhưng tôi không muốn buộc các lập trình viên sáng tạo trong bộ đồ không phù hợp với họ.

Vì vậy, câu hỏi là: Có cách nào để mỗi lập trình viên sống theo phong cách riêng của mình, nhưng có một cơ sở mã chung trong kho lưu trữ không? Tôi nghĩ về một số plugin git / svn / bất cứ thứ gì, thay đổi giữa phong cách cá nhân và phổ biến khi thanh toán và cam kết. Tôi nhận thấy rằng phần khó khăn trong phương pháp này là hỗ trợ các khác biệt chính xác giữa các phiên bản của một tệp

Không, bạn sẽ cần phải làm cho một tiêu chuẩn. Nếu bạn có thay đổi thành viên nhóm B (bằng công cụ IDE tự động hoặc thủ công), cả đống thành viên nhóm mã A đã viết, điều đó sẽ được cam kết và hiển thị dưới dạng thay đổi.

Đây là điều mà hầu hết mọi đội bóng phải đối mặt và các tiêu chuẩn bị "ép buộc" vì chính lý do này. Tôi sẽ đề nghị bạn tuân theo các tiêu chuẩn của cơ quan ngôn ngữ làm cơ sở và áp dụng chúng cho phù hợp với nhóm của bạn.

Có một phong cách mã hóa nhất quán cũng sẽ giúp duy trì khả năng duy trì của dự án và giảm rào cản gia nhập cho những người mới làm việc với mã.

Không, bạn sẽ cần xác định một tiêu chuẩn mã hóa (tốt nhất là một tiêu chuẩn đã tồn tại) và để các nhà phát triển của bạn tuân thủ nó. Trở thành một lập trình viên chuyên nghiệp có nghĩa là bạn có thể thích nghi với mọi tiêu chuẩn mã hóa được sử dụng trong dự án mà bạn đang làm việc.

CÓ, nó có thể hoạt động miễn là các kiểu đều hợp lý và mọi người không đi xung quanh thay đổi mã của người khác để phù hợp với sở thích của họ và / hoặc trộn các kiểu trong một tệp mã.
Điều đó không lý tưởng, nhưng nó không khác gì việc kế thừa mã cũ được tạo thành một "tiêu chuẩn" khác với chính bạn và phải tích hợp nó với cơ sở mã của bạn.
Vì vậy, nếu bạn phải làm điều đó, một số hướng dẫn:

• không thay đổi mã theo kiểu khác nhau để phù hợp với sở thích của bạn, nó tốn thời gian và gây ra lỗi
• vẫn nhất quán trong bất kỳ tập tin duy nhất. Vì vậy, nếu kiểu A được sử dụng để viết nó ban đầu, mọi người sẽ sử dụng kiểu A khi sửa đổi nó
• hãy tạo một tiêu chuẩn chung cho giao diện chung của bạn, vì vậy đối với mọi thứ tiếp xúc với bên ngoài (và vâng, các thành phần phụ khác của hệ thống là bên ngoài).

Câu trả lời ngắn gọn là không.

Mặc dù các ý kiến ​​sẽ được coi trọng trong công việc, đặc biệt là trong một công việc dựa trên kiến ​​thức như Phát triển phần mềm, các nhà phát triển phải nhận ra rằng một ý kiến ​​chỉ là ý kiến ​​và họ ở đó để viết phần mềm không tranh luận về tiêu chuẩn thụt dòng nào là tốt nhất.

Mục tiêu của một tài liệu tiêu chuẩn nên là thực thi / đề xuất một tập hợp các tiêu chuẩn / quy ước mã hóa phổ biến nhằm giải quyết

1. Các mục Bố cục như tab, thụt lề, sử dụng {, (,
2. Tên biến, đối tượng và chức năng, ví dụ như CamelCase, ký hiệu Hungary
3. Xử lý ngoại lệ cách thức / thời gian / địa điểm được thực hiện
4. Mã nhận xét. Bạn có luôn tham khảo tài liệu thiết kế, số lỗi không?

Các tài liệu tiêu chuẩn giúp đảm bảo rằng mã dễ đọc, duy trì và nhất quán trong các quy ước của nó.

Điều này là vô giá khi xem xét mã trước khi đăng ký, gỡ lỗi mã của ai đó hoặc sửa đổi mã vài năm sau khi nhà phát triển ban đầu rời khỏi công ty.

Thông thường khi tạo tài liệu Tiêu chuẩn mã hóa, tôi xem xét các tiêu chuẩn ngành cho ngôn ngữ tôi đang sử dụng (C, C #, SQL), sử dụng các tiêu chuẩn phù hợp nhất, lưu hành cho các nhà phát triển cao cấp / có ảnh hưởng nhất để bình luận, kết hợp các nhận xét khi thích hợp và sau đó phát hành tài liệu.

Về mặt lý thuyết, việc tự động định dạng lại mã trước khi cam kết với hệ thống kiểm soát phiên bản của bạn là có thể.

Tuy nhiên , có một vấn đề lớn: các công cụ định dạng mã tự động không đáng tin cậy 100%. Vì vậy, bạn thực sự có thể giới thiệu các vấn đề trong mã của bạn với hệ thống này. Trong tâm trí của tôi, điều đó giết chết ý tưởng. Luôn luôn quan trọng để có mã chức năng hơn mã được tạo kiểu đúng!

Nếu dự án được ngăn xếp và hầu hết các phần của mã có xu hướng được "sở hữu" bởi các lập trình viên riêng lẻ, thì có thể cho phép họ sử dụng các kiểu riêng của họ (theo lý do). Tuy nhiên, nếu một số người thường xuyên làm việc trên cùng một đoạn mã, có lẽ cần phải thực thi một kiểu.

Đây là một cuộc thảo luận tương tự về Stack Overflow .

Mã định dạng lại tự động một chiều có thể là một giải pháp khả thi nếu bạn:

1. Tìm một bộ lọc tự động thực sự hoạt động cho quy ước bạn muốn thực hiện và ngôn ngữ lập trình của bạn.
2. Có thể thực hiện trước khi cam kết để việc định dạng lại không hiển thị trong nhật ký thay đổi được trộn lẫn và không thể phân biệt với các thay đổi chức năng thực tế.
3. Quản lý để khiến nhóm của bạn đồng ý về việc nên áp dụng quy ước nào (vì nói chung, không có "đường quay lại" khi trả phòng theo sở thích cá nhân của nhà phát triển, ít nhất là tôi không biết).

Không ai trong số đó thực sự dễ làm trong nhiều trường hợp, vì vậy hãy cân nhắc chọn các trận đánh của bạn ở đây! Tôi đã thấy các nhóm thực hiện thành công điều này cho một dự án C # /. NET nơi việc định dạng lại đã xảy ra trên PC của nhà phát triển, do đó, trong một số trường hợp có thể xảy ra.

hoàn toàn bạn có thể Đó là tất cả về không đổ mồ hôi những thứ nhỏ.

Tiêu chuẩn duy nhất quan trọng là "giữ cho các thay đổi của bạn có cùng kiểu với mã hiện có". Miễn là bạn có thể phù hợp với phong cách mã hóa không phải là kiểu ưa thích của bạn, thì bạn có thể làm việc với bất kỳ kiểu mã hóa nào.

Vì vậy, vấn đề lớn về làm việc theo 3 phong cách khác nhau trong cùng một công ty. Các nhà phát triển của bạn cần hiểu điều này, rằng viết mã theo cách họ thích là tìm mã của họ nhưng một khi họ thay đổi tệp khác sử dụng một kiểu khác, họ phải duy trì kiểu đó (hoặc nó sẽ thực sự trông tệ) . Không cho phép định dạng lại (hoặc họ sẽ chỉ định dạng lại liên tục và scm diffs sẽ vô dụng) (và nếu bạn làm điều này, thì nên sử dụng định dạng tự động).

Rất có thể, một khi họ bắt đầu với điều này, họ sẽ đi đến một sự đồng thuận về việc sử dụng phong cách nào hoặc phong cách của họ sẽ trôi cùng nhau trong hầu hết các phần. Nếu họ sẽ trẻ con về điều đó và sẽ định dạng lại mã cho nhau mọi lúc, thì đã đến lúc tải xuống một tiêu chuẩn từ internet và yêu cầu họ sử dụng nó. Dù sao thì bạn cũng có thể muốn làm điều này, chỉ cần vẫy nó vào mặt họ như một lá bài "chơi đẹp hay khác".