Ưu điểm và nhược điểm của cải cách mã cưỡng bức

Tôi hiện đang làm việc tại một nơi có thể đang xem xét việc buộc các nhà phát triển sử dụng trình định dạng mã tự động khi đăng ký kiểm soát phiên bản. Tôi đang tìm kiếm ý kiến ​​của các nhà phát triển về những lợi thế và bất lợi của việc này ... cách bạn nghĩ nó sẽ giúp hoặc cản trở các nhà phát triển. Trường hợp cụ thể của tôi liên quan đến Java / JSP, nhưng tôi nghĩ rằng câu hỏi có thể áp dụng cho bất kỳ ngôn ngữ nào.

Tôi nghĩ nó rất quan trọng để làm điều này. Đây là lý do tại sao:

• Nó làm cho điều khiển nguồn khác biệt của bạn chỉ hiển thị các thay đổi mã thực tế và loại bỏ "nhiễu khác biệt" do khoảng trắng và các lựa chọn định dạng không đáng kể khác
• Nó làm cho tất cả các mã giống nhau hơn, để các nhà phát triển dễ dàng ghép nối và chia sẻ các cơ sở mã hơn

Nếu bạn làm điều đó, tôi sẽ khuyên mọi người nên kiểm tra tất cả mã, sau đó một người sẽ định dạng lại toàn bộ cơ sở mã, sau đó kiểm tra lại tất cả để có một thay đổi "khổng lồ" được định dạng (mà mọi người đều có thể bỏ qua), nhưng Sau đó, tất cả các khác biệt là khác biệt mã thực.

Nếu bạn làm từng chút một, bạn sẽ trộn các thay đổi mã thực với các thay đổi định dạng và mọi thứ sẽ trở nên lộn xộn không cần thiết trong vùng đất thay đổi.

Tôi sẽ đưa ra câu trả lời của riêng mình ở đây vì mọi người dường như chỉ đang thêm lợi thế. Những gì tôi thấy là nhược điểm là:

• Loại bỏ khả năng làm 'tốt hơn' so với trình định dạng tự động ... nó sẽ hoàn tác định dạng sạch hơn của bạn. Một ví dụ về điều này sẽ là các khai báo tham số dựa trên cột, danh sách các bổ sung riêng biệt của các đối tượng, v.v.
• Tạo ra một khả năng chống lại các quy ước phong cách thay đổi vì những điều này bây giờ sẽ tạo ra những thay đổi khác biệt lớn gây hiểu lầm.
• Loại bỏ khả năng thực hiện bất kỳ định dạng 'trường hợp đặc biệt' nào trong đó một định dạng thay thế sẽ giúp mã dễ đọc hơn.
• Nó ràng buộc bạn sử dụng các IDE hỗ trợ chính xác các tính năng định dạng lại mà bạn cần. Trong một IDE khác thiếu một trong các tùy chọn bạn cần, nó sẽ gây ra ít nhất một số vấn đề.
• Việc chia sẻ kho lưu trữ mã có thể ghi được với một nhóm bên ngoài trở nên có vấn đề trừ khi họ sử dụng các quy ước định dạng chính xác giống như nhóm của bạn (Họ thường sẽ, nhưng không phải lúc nào cũng vậy).
• Luôn luôn có những trường hợp ngoại lệ trong đó một định dạng hơi khác có khả năng sạch hơn kiểu quy định. Do đó, tự động chuyển đổi thường có thể che giấu ý định của các khối mã nhất định, điều này thực sự tốt như việc thêm một khiếm khuyết vào mã.

Nói một cách đơn giản, một tập hợp các quy ước không tự động đặt ra các yêu cầu về kiểu dáng / khả năng đọc tối thiểu, trong đó các quy ước tự động đặt mức tối thiểu và tối đa.

Tôi nhớ đã nhìn vào VB (có thể là phiên bản 5) và tìm thấy một trong những điều khó chịu nhất về nó là nó sẽ định dạng lại mã của tôi và loại bỏ những thứ ở trên và ngoài định dạng cơ bản của nó.

Tôi thấy rằng định dạng mã bắt buộc là tuyệt vời. Nó cho phép một nhà phát triển duyệt qua toàn bộ kho mã mà không bị đảo mắt ở mọi nơi. Cũng có tiêu chuẩn này tại chỗ giúp các nhà phát triển mới làm quen phá vỡ các thói quen xấu.

Bất lợi chính là mất định dạng tùy chỉnh, nơi nó thực sự quan trọng.

Hãy tưởng tượng một kiểm tra vệ sinh điển hình nếu () sẽ thất bại nếu có bất kỳ điều kiện cụ thể nào nhưng không được đáp ứng ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Điều này có thể đọc được nhờ thụt lề hợp lý theo cấu trúc logic của các điều kiện.

Bây giờ công cụ tự động của bạn không có đầu mối nào về việc tách logic các điều kiện khác nhau thành các dòng liên quan. Nó thấy không có lý do tại sao mỗi cụm 3-4 điều kiện trong một dòng và chia điều kiện tiếp theo làm đôi. Hoặc nó sẽ phân tách nó, một biểu thức so sánh trên mỗi dòng. Nó thậm chí có thể trông đẹp hơn trên màn hình nhưng logic sẽ bị mất.

Tôi đã thêm một câu trả lời với những bất lợi, và tôi cũng sẽ đưa ra những gì tôi coi là một lợi thế lớn.

Khi bạn sử dụng một định dạng lại mã tự động trên cam kết, nó thực sự mở ra khả năng biến đổi sở thích cá nhân mà không có tác động thông thường là khiến sở thích của bạn gây ra cho người khác. Bạn có thể có mã định dạng IDE của mình theo một tiêu chuẩn chung về cam kết, nhưng hiển thị nó cho bạn ở định dạng ưa thích mà không ảnh hưởng đến người khác.

Điều này với tôi gần như là Chén Thánh của mã hóa dựa trên quy ước ... bạn có được những lợi thế của định dạng mã phổ biến, nhưng vẫn cho phép các tùy chọn cá nhân được hỗ trợ mà không có xung đột.

Nó phụ thuộc vào nhu cầu của bạn, nhưng một số điều kiện chống đối khá hữu ích, ví dụ như mọi if () nên được theo sau bởi dấu ngoặc nhọn, vì khá dễ để có được một lỗi như vậy nếu bạn tái cấu trúc.

Hãy xem xét trường hợp đó:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Nếu bây giờ bạn muốn thêm một số ghi nhật ký vào trường hợp nếu bạn có thể vô tình viết:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

Và hoàn toàn phương pháp của bạn luôn luôn trở lại foo.

Chỉnh sửa: đó không phải là định dạng tự động mà là kiểm tra kiểu. Xin lỗi nếu câu trả lời đó cũng lạc đề. :)

Nó giúp ích rất nhiều cho việc thống nhất mã trong công ty và nhờ đó bạn thường tạo ra một cấu trúc dễ hiểu hơn và dễ bảo trì hơn cho sản phẩm của bạn.

Vâng, những ưu điểm cũng giống như bất kỳ định dạng mã, như tiêu chuẩn của mã, ngữ nghĩa giữa các nhà phát triển, vv chỉ bất lợi có thể tôi thấy là việc thiếu một mắt người sau khi các định dạng, thêm một số trường hợp ngoại lệ, vv
Vì vậy, tôi đoán tốt hơn là xem xét một trình định dạng IDE thay vì một trình định dạng thời gian đăng ký.

Theo kinh nghiệm của tôi, đó là một điều tốt. Không có ai, so sánh mã thường hiển thị một mớ hỗn độn về định dạng khoảng trắng và có thể ẩn các thay đổi mã thực tế. Theo kinh nghiệm của tôi, việc nhầm lẫn với định dạng của ai đó không phải là tội lỗi mà nó tạo ra, đặc biệt là với những lợi ích tiềm năng của tính nhất quán trong toàn đội.