Mã định dạng và kiểm soát nguồn khác nhau

Question

Sản phẩm điều khiển nguồn nào có cơ sở "khác" bỏ qua khoảng trắng, niềng răng, v.v., để tính toán sự khác biệt giữa các phiên bản đã đăng ký? Tôi dường như nhớ rằng diff của Clearcase đã làm điều này nhưng Visual SourceSafe (hoặc ít nhất là phiên bản tôi sử dụng) không.

Lý do tôi hỏi có thể khá điển hình. Bốn nhà phát triển hoàn toàn hợp lý trong một nhóm có bốn cách hoàn toàn khác nhau để định dạng mã của họ. Khi kiểm tra mã thay đổi lần cuối bởi người khác, mỗi mã sẽ ngay lập tức chạy một số loại macro chương trình hoặc trình chỉnh sửa để định dạng mọi thứ theo cách mà họ muốn. Họ thực hiện thay đổi mã thực tế. Họ kiểm tra những thay đổi của họ. Họ đi nghỉ mát. Hai ngày sau, chương trình đó, đã hoạt động tốt trong hai năm, thổi lên. Nhà phát triển được gán cho lỗi thực hiện một sự khác biệt giữa các phiên bản và tìm thấy 204 khác biệt, chỉ 3 trong số đó có ý nghĩa quan trọng, bởi vì thuật toán khác bị lame.

Có, bạn có thể có các tiêu chuẩn mã hóa. Hầu hết mọi người đều thấy họ kinh khủng. Một giải pháp mà tất cả mọi người có thể có bánh của họ và ăn nó quá dường như thích hợp hơn nhiều.

=========

EDIT: Nhờ tất cả mọi người đối với một số gợi ý tuyệt vời.

Những gì tôi lấy đi từ điều này là:

(1) Hệ thống kiểm soát nguồn với loại khác biệt là thích hợp hơn.

(2) Tìm sự khác biệt với các tùy chọn phù hợp.

(3) Sử dụng chương trình định dạng nguồn tốt và giải quyết theo tiêu chuẩn đăng ký.

Có vẻ như một kế hoạch. Cảm ơn một lần nữa.

Answer 1

Có lẽ bạn nên chọn một định dạng và chạy một số công cụ thụt lề trước khi đăng ký để mỗi người có thể xem, định dạng lại tùy chọn của riêng mình, thực hiện thay đổi, định dạng lại chuẩn chính thức và sau đó đăng ký?

Một vài bước bổ sung nhưng họ đã sử dụng các công cụ thụt lề khi làm việc. Có lẽ nó có thể là một kịch bản check-in kích hoạt?

Chỉnh sửa: điều này có lẽ cũng sẽ giải quyết được vấn đề về cú đúp.

(Tôi chưa tự mình thử giải pháp này, do đó là "perhapes" và "maybes", nhưng tôi đã tham gia vào các dự án có cùng vấn đề, và đó là một nỗi đau các thay đổi không giới hạn ở khoảng trắng, nhưng bao gồm cả định dạng.)

Answer 2

Subversion có vẻ hỗ trợ điều này, hoặc là tự nhiên trong các phiên bản mới nhất hoặc bằng cách sử dụng khác thay thế như Gnu Diff.

Answer 3

Git không có các tùy chọn này:

• --ignore-space-at-eol

  Bỏ qua những thay đổi về khoảng trắng tại EOL.

• -b, --ignore-space-change

  Bỏ qua những thay đổi về số lượng khoảng trắng.Điều này bỏ qua khoảng trắng ở cuối dòng và xem xét tất cả các chuỗi khác của một hoặc nhiều ký tự khoảng trắng tương đương.

• -w, --ignore-all-space

  Bỏ qua khoảng trắng khi so sánh dòng. Điều này bỏ qua sự khác biệt ngay cả khi một dòng có khoảng trống trong đó dòng khác có không.

Tôi không chắc chắn nếu thay đổi cú đúp có thể bỏ qua bằng cách sử dụng khác biệt của Git.

Nếu đó là mã C/C++, bạn có thể xác định các quy tắc Astyle và sau đó chuyển đổi kiểu dấu ngoặc của mã nguồn thành kiểu bạn muốn, sử dụng Astyle. A git diff sau đó sẽ tạo ra đầu ra sane.

Answer 4

Ngoài so sánh thực hiện điều này (và nhiều hơn nữa) và bạn có thể tích hợp nó trong Subversion hoặc Sourcesafe như một công cụ tìm khác biệt bên ngoài.

Answer 5

Như được giải thích trong Is it possible for git-merge to ignore line-ending differences?, việc kết hợp công cụ tìm khác biệt phù hợp với VCS yêu thích của bạn hơn là dựa vào tùy chọn VCS phù hợp (ngay cả khi Git có một số tùy chọn liên quan đến khoảng trắng) Alan's answer, nó sẽ luôn không hoàn chỉnh như mong muốn).

DiffMerge là đầy đủ hơn về các tùy chọn "bỏ qua", vì nó không chỉ bỏ qua dấu cách mà còn có thể "biến thể" khác dựa trên ngôn ngữ lập trình được sử dụng trong tệp nhất định.

Answer 6

Chọn một tiêu chuẩn mã hóa (đáng sợ), viết xuống trong một số tài liệu tiêu chuẩn mã hóa chính thức và tiếp tục với cuộc sống của bạn, gây rối với khoảng trắng không phải là công việc hiệu quả. Và hãy nhớ rằng bạn là một nhà phát triển chuyên nghiệp, đó là công việc của bạn để hoàn thành dự án, thay đổi bất kỳ thứ gì trong mã vì sở thích kiểu cá nhân gây tổn hại cho dự án - nó không chỉ làm cho khó khăn hơn, nó còn có thể giới thiệu khó tìm thấy vấn đề nếu trình định dạng nguồn hoặc trình biên dịch của bạn có lỗi (và công cụ tìm kiếm ưa thích của bạn sẽ không giúp bạn tiết kiệm khi hai đồng nghiệp bắt đầu chiến đấu trên vỏ).

Và nếu ai đó chỉ không đồng ý làm việc với phong cách chọn chỉ nhắc nhở anh ta (hay cô ấy) rằng ông là lập trình là một nghề không phải là một sở thích, xem http://www.ericsink.com/entries/No_Great_Hackers.html