Có thể định dạng lại mã nhà phát triển khác trong khi sửa đổi / thêm vào mô-đun không?

Trong khi phát triển trong một bầu không khí nhóm và thêm hoặc sửa đổi các tính năng trong một số cơ sở mã. Nó được coi là xúc phạm hoặc bất lịch sự để định dạng lại mã nhà phát triển trước đó để đưa nó lên các tiêu chuẩn mã hóa hiện tại? Tôi hiểu rằng các tiêu chuẩn đã thay đổi và có thể sẽ tiếp tục thay đổi, nhưng liệu có ai trong số bạn bị xúc phạm nếu ai đó đi qua và thay đổi định dạng mã của bạn không?

Để rõ ràng, tôi không nói về việc thay đổi bất kỳ logic nào, chỉ gây rối với các tab và khoảng trắng và như vậy.

EDIT: Tôi không chỉ làm điều này vì mục đích của các tiêu chuẩn mã hóa, nó giúp tôi đọc qua mã của họ và cập nhật nó để tôi có thể hiểu đầy đủ logic đã được triển khai trước khi tôi bắt đầu sửa đổi các ứng dụng quan trọng.

Tôi nghĩ rằng điều này là ổn miễn là các tiêu chuẩn được thỏa thuận. Tuy nhiên, một lưu ý cần thận trọng; lưu ý nếu có tiềm năng tập tin đang được người khác sửa đổi cùng một lúc. Nếu bạn làm cho việc hợp nhất của họ khó khăn hơn chỉ vì bạn đang thay đổi định dạng, bạn sẽ không nổi tiếng.

Có, mã nên thuộc về dự án. Đưa mã theo tiêu chuẩn sẽ giúp giảm thâm hụt kỹ thuật của dự án. Nếu bạn đang sửa đổi nó, bạn hiện đang chịu trách nhiệm cho nó. Đối với mã cũ, nhà phát triển ban đầu có thể không còn trong dự án hoặc có nhiệm vụ mới.

Khi bạn thực hiện loại thay đổi này, tốt nhất là chạy các kiểm tra xác minh sau khi định dạng lại. Nếu họ vượt qua, hãy kiểm tra mã trước khi thay đổi tính năng của bạn.

EDIT: Trong bối cảnh của câu hỏi này, định dạng lại theo tiêu chuẩn là phù hợp. Trong trường hợp không có tiêu chuẩn, tôi sẽ khuyên bạn nên ủng hộ các tiêu chuẩn và không định dạng lại cho đến khi có các tiêu chuẩn cho định dạng. Định dạng lại theo sở thích / tiêu chuẩn cá nhân không nên được thực hiện với mã thuộc về dự án.

Tôi tin rằng luôn luôn là một cách thực hành tốt để cấu trúc lại mã khi bạn sửa đổi / thêm vào một tệp cụ thể. Điều đó bao gồm việc cập nhật kiểu mã để phản ánh các quy ước đặt tên thích hợp cho các biến / phương thức và kiểu mã hóa.

Tôi làm điều này tất cả các thời gian. Mã cũ phải được giữ theo cùng tiêu chuẩn của mã mới và nếu bạn không sửa nó trong khi bạn đang làm việc với nó thì sẽ không có ai làm như vậy. Tôi nghĩ rằng điều này được tính theo Quy tắc Hướng đạo Nam.

Tôi nghĩ rằng đây là một thực hành tốt và một phần cần thiết của bảo trì mã.

Tôi sẽ khuyên bạn nên kiểm tra các thay đổi định dạng trong một cam kết đối với hệ thống kiểm soát phiên bản và các thay đổi chức năng trong một cam kết riêng biệt để giúp cả bạn và những người khác hiểu những gì đã diễn ra.

Tôi sẽ không có bất kỳ vấn đề nào với nó và có lẽ sẽ đánh giá cao nó ... miễn là những thay đổi không "đáng tin cậy". Xin vui lòng không đi qua tất cả các lớp học của tôi và di chuyển các dấu ngoặc nhọn đến dòng đầu tiên của phương thức. Nếu định dạng là một kiểu "khác nhau cho những người khác nhau" hợp pháp, thì sẽ hơi khó chịu khi ai đó đi vào và áp đặt một định dạng trên mã mà bạn thường xuyên chỉnh sửa. Tuy nhiên, nếu bạn trở thành biên tập viên chính của mô-đun cụ thể đó, thì hãy thực hiện mọi thay đổi định dạng mà bạn thấy phù hợp.

Đúng. Vui lòng "sửa" mã khi bạn thấy phù hợp. Giống như các lập trình viên thực dụng nói trong cuốn sách Lập trình viên thực dụng của họ , không có cửa sổ bị phá vỡ. Nếu mã không ngang bằng, tôi coi đó là một cửa sổ bị hỏng.

Có nhiều kho lưu trữ khác nhau sẽ tự động định dạng lại khi đăng ký cũng như những việc nhỏ như thay đổi ghép cặp CR / LF tùy thuộc vào nền tảng lấy nguồn.

Có một nhược điểm rất lớn khi thực hiện các định dạng riêng của bạn ở chỗ việc kiểm tra đồng bằng của bạn sẽ bị xáo trộn bởi hàng tấn định dạng lại và nếu có vấn đề hồi quy thì việc tìm các khối mã vi phạm sẽ trở nên khó khăn hơn.

Bạn có thể đề xuất với khách hàng tiềm năng của mình rằng vì cơ sở mã đã cũ nên được đưa vào từ lạnh và được định dạng lại theo các tiêu chuẩn hiện tại trong một lần, dẫn đến một tương lai mới cho mã ở mọi nơi.

Vì bạn đang nói về một vấn đề "định dạng" hoàn toàn (có nghĩa là chúng tôi không sửa lỗi nhưng làm cho nó trông đẹp theo tiêu chuẩn của riêng bạn), tôi nghĩ điều đó phụ thuộc vào việc người ban đầu có còn duy trì mã hay không.

Nếu người khởi tạo vẫn đang làm việc trên dự án - đó là thô lỗ. Những gì có thể "trông" đúng với bạn không phải là những gì sẽ "nhìn" đúng với họ và sửa đổi mã vì mục đích định dạng không lịch sự. Nó cũng có thể lãng phí rất nhiều thời gian.

Tôi đã làm việc trên một dự án một lần với một nhà phát triển sở hữu RẤT. Trong những năm qua, tôi đã phát triển một cách định dạng mã rất có phương pháp mà tôi cảm thấy dễ đọc, ít mắc các lỗi ngầm định và tự viết tài liệu. Mặt khác, anh chàng này thích sử dụng tất cả các tính năng tiềm ẩn với các dòng dài trải rộng 300 ký tự để bạn phải có màn hình 30 "để đọc nó vì anh ta tin rằng số dòng quan trọng hơn khả năng đọc. Anh ta đã dành nửa ngày thổi qua mã của tôi thay đổi nó thành "tiêu chuẩn ưa thích" của anh ấy ... trong khi tôi vẫn đang phát triển song song! Tôi đến vào sáng hôm sau để tìm công việc đáng giá hai ngày được định dạng cho mớ hỗn độn của anh ấy. Thật thô lỗ và lãng phí thời gian.

Bây giờ nếu nhà phát triển không còn nữa và bạn có "phong cách tốt hơn" thì hãy tìm nó.

Luôn tự động định dạng mã nếu IDE của bạn có thể làm điều đó.

• Ngăn chặn các thay đổi định dạng thủ công khỏi làm lộn xộn lịch sử phiên bản của bạn trong thời gian dài
• Cấu hình định dạng phải được sự đồng ý giữa tất cả các nhà phát triển (chọn mặc định? -)
• Tạo mã định dạng và tổ chức nhập khẩu thành thói quen khi lưu tệp

Ví dụ: trong nhật thực, trước tiên bạn có thể chạy trình định dạng và tổ chức nhập cho toàn bộ cơ sở mã. Sau đó hãy nhớ ctrl + alt + f trước khi bạn lưu.