Gần đây, tôi đã bắt gặp một số dự án Ruby nguồn mở (hoặc phần lớn trong số đó là Ruby) trên GitHub mà khi được kiểm tra bằng một công cụ phân tích mã như Rubocop , tạo ra rất nhiều hành vi phạm tội .

Bây giờ, hầu hết các vi phạm này bao gồm sử dụng dấu ngoặc kép thay vì dấu ngoặc đơn (khi không nội suy), không tuân theo quy tắc 2 khoảng trắng trên mỗi cấp, vượt quá quy tắc độ dài 80 ký tự hoặc sử dụng {và }cho các khối nhiều dòng.

[Hướng dẫn] Phong cách Ruby khuyên bạn nên thực hành tốt nhất để các lập trình viên Ruby trong thế giới thực có thể viết mã có thể được duy trì bởi các lập trình viên Ruby trong thế giới thực khác. ~ Nguồn: Hướng dẫn phong cách Ruby

Mặc dù chúng nhỏ và dễ sửa, nhưng có phù hợp để thay đổi phong cách mã hóa của một dự án nguồn mở bằng cách sửa các vi phạm và thực hiện Yêu cầu Kéo không? Tôi thừa nhận rằng một số dự án, như Rails, không chấp nhận thay đổi mỹ phẩm và một số dự án quá lớn để "sửa chữa" cùng một lúc (ví dụ, Rails tạo ra hơn 80.000 vi phạm khi Rubocop được chạy - bất kể, chúng có bộ mã hóa nhỏ của riêng chúng quy ước cần tuân thủ khi đóng góp). Rốt cuộc, Hướng dẫn về Phong cách Ruby là có lý do cùng với các công cụ như Rubocop.

Mọi người đánh giá cao tính nhất quán vì vậy thực hiện các loại thay đổi này là một cách làm tốt cho cộng đồng Ruby nói chung, phải không?

[Tác giả của Hướng dẫn về Phong cách Ruby] đã không đưa ra tất cả các quy tắc từ đâu cả - họ chủ yếu dựa trên sự nghiệp rộng rãi của tôi là một kỹ sư phần mềm chuyên nghiệp, phản hồi và đề xuất từ ​​các thành viên của cộng đồng Ruby và nhiều người khác tài nguyên lập trình Ruby được đánh giá cao, chẳng hạn như "Lập trình Ruby 1.9" và "Ngôn ngữ lập trình Ruby". ~ Nguồn: Hướng dẫn phong cách Ruby

Không tuân theo các quy ước về phong cách mã hóa cộng đồng và các thực tiễn tốt nhất về cơ bản khuyến khích các thực hành xấu ?

Hỏi người bảo trì.

Kiểu mã hóa là một cuộc thảo luận khá chủ quan và các quy tắc như độ dài dòng tối đa 80 ký tự là khá chủ quan - trong khi thỏa thuận chung là các dòng ngắn hơn nên đọc tốt hơn, 80 có thể quá hạn chế đối với một số người có kích thước màn hình và IDE ngày nay.

Các quy tắc khác có thể được bỏ qua trên mục đích, quá. Chẳng hạn, một nhà phát triển có thể xem xét việc sử dụng dấu ngoặc kép trên toàn cầu tốt hơn cho anh ta và sẵn sàng chấp nhận "rủi ro" của phép nội suy ngẫu nhiên và sự gia tăng cực kỳ nhỏ về thời gian phân tích cú pháp.

Nhiều nhà bảo trì cũng không thích thay đổi kiểu mã hóa lớn vì họ thấy nhàm chán khi xem xét và có khả năng nó có thể gây ra lỗi. Ví dụ, một chuỗi có thể được chuyển sang trích dẫn đơn, mặc dù nó chứa nội suy có chủ ý và nên sử dụng dấu ngoặc kép. Các nhà bảo trì thích làm sạch kiểu trong khi làm việc với mã thực tế đó để họ có thể xác minh các thay đổi kiểu không đưa ra các lỗi mới.

Bạn dường như bị thúc đẩy phần lớn bởi sự tôn trọng quyền lực của công cụ rubocop và Hướng dẫn phong cách Ruby, mà những người bảo trì không thể chia sẻ. Họ đã có phong cách riêng và đã quen với nó, vì vậy mọi thay đổi sẽ ảnh hưởng đến mọi người làm việc trong dự án và đó là rất nhiều công việc, đặc biệt là nếu dự án lớn.

Hãy xem xét các động lực của những người duy trì. Họ (có thể) muốn những người mới tham gia với họ bằng cách gửi các lỗi, báo cáo lỗi, mã làm việc và tài liệu được viết tốt. Nếu bạn xuất hiện và nói "Bạn có hành vi phạm tội trong rubocop" thì họ sẽ không nghĩ "Ồ tốt, ai đó mới giúp chia sẻ tải", họ sẽ nghĩ "Anh chàng này là ai? Tại sao anh ta lại nói với chúng tôi phải làm sao? ".

Các dự án nguồn mở có xu hướng công đức: bạn có được sự tôn trọng dựa trên chất lượng công việc của bạn. Nếu bạn xuất hiện và làm những điều tuyệt vời và sau đó nêu lên mối quan tâm về phong cách của bạn, họ có nhiều khả năng lắng nghe, mặc dù họ vẫn có thể nói không. Có một nguồn mở nói rằng "Nói là rẻ, cho tôi xem mã".

Chủ nghĩa thực dụng hơn Dogma, luôn luôn. Hướng dẫn phong cách mã hóa là một hình thức xấu xa đặc biệt quỷ quyệt thu hút sự chú ý khỏi các mối quan tâm về kiến ​​trúc đối với những điều vô nghĩa phù phiếm như trích dẫn đơn / đôi. Hãy tự hỏi: nó có thực sự tạo ra sự khác biệt?

Họ có thể tốt đến một điểm, nhưng lần thứ hai bạn đối xử với họ với sự nhiệt thành gần như tôn giáo, bạn đã đi quá xa. Chúng là những hướng dẫn, gợi ý, ý kiến, KHÔNG phải sự thật.

Họ có nên bỏ qua không? Không, có công sử dụng các công cụ để có được một ý tưởng chung về những gì cần phải xem xét, nhưng không còn nữa.

Đó là một thắc mắc về mức độ thường xuyên các loại cơ sở nhầm lẫn ý kiến ​​cho thực tế.

Bạn chỉ có thể kéo những thay đổi này nếu có sự cố mở để sửa định dạng. Nếu không, hãy bắt đầu chi nhánh của riêng bạn và nếu tác giả thấy rằng nhiều người sử dụng chi nhánh của bạn đơn giản hơn vì nó dễ đọc hơn. Họ sẽ tự hợp nhất trong chi nhánh, nhưng hãy chuẩn bị để duy trì chi nhánh của bạn bằng cách hợp nhất trong các bản cập nhật và liên tục sửa định dạng.

Nếu dự án không đủ quan trọng với bạn để duy trì chi nhánh của riêng bạn, thì ngay từ đầu, nó không đáng để làm sạch.

Yêu cầu kéo có thể được thực hiện cá nhân của tác giả. Đây không phải là một cơ chế để đưa ra lời chỉ trích và định dạng lại tất cả các mã có thể được coi là lời chỉ trích.

Nếu bạn không muốn duy trì chi nhánh của riêng mình, nhưng bạn muốn đóng góp cho một dự án. Mở một vấn đề mới và mô tả lý do tại sao định dạng hiện tại gây ra sự cố cho bạn, sau đó đề nghị giải quyết vấn đề cho tác giả. Nếu tác giả đồng ý, thì họ sẽ chỉ định vấn đề cho bạn và bây giờ bạn có quyền đưa ra yêu cầu kéo.

Bạn đã chạm vào một chủ đề mà tôi cũng đồng ý là một vấn đề tràn lan trên GitHub . Định dạng sang một bên, có một số dự án sử dụng chú thích không chính xác và gây ra sự tàn phá với nhiều IDE. Tôi có thể nghĩ về ba dự án phổ biến chủ yếu sử dụng cờ không dùng nữa để truyền bá thông điệp cảnh báo trong IDE của tôi. Tôi đã gửi yêu cầu kéo để sửa chúng, nhưng các tác giả không sử dụng cùng một IDE, do đó các yêu cầu kéo bị bỏ qua.

Phân nhánh, sáp nhập và sửa chữa dường như là giải pháp duy nhất.

Lấy từ trang Rubocop (nhấn mạnh của tôi):

Một điều luôn làm tôi bận tâm khi là nhà phát triển Ruby - Các nhà phát triển Python có tài liệu tham khảo phong cách lập trình tuyệt vời (PEP-8) và chúng tôi chưa bao giờ có hướng dẫn chính thức , ghi lại phong cách mã hóa Ruby và các thực tiễn tốt nhất.

Làm ơn hãy hiểu:

Không có Hướng dẫn về Phong cách Ruby chính thức

Tôi không nói rằng hướng dẫn phong cách là xấu. Nhưng không chỉ không có hướng dẫn chính thức, mà có một hướng dẫn phong cách là một lựa chọn được thực hiện trên cấp độ cá nhân, dự án, nhóm, công ty. Hướng dẫn phong cách, để sử dụng một thuật ngữ tâm lý học, một "chuẩn mực xã hội trong nhóm".

Điều đó có ý nghĩa gì với bạn? Chà, nếu bạn không được coi là một phần của nhóm, điều đó có nghĩa là bất cứ điều gì bạn - hoặc bất kỳ trang web nào khác nói - rất khó có thể gây ảnh hưởng với nhóm. Vì vậy, nếu bạn không phải là người đóng góp tích cực, được tôn trọng cho dự án cụ thể đó thì rất có thể các đề xuất của bạn sẽ bị bỏ qua hoặc tốt nhất sẽ là một lời nhắc nhở về những cân nhắc trước đây về việc có một hướng dẫn phong cách. Tệ nhất, nó sẽ được coi là một sự xúc phạm, hoặc như một người xen kẽ hoặc người đi xe đạp dán mũi vào nơi không thuộc về nó.

Bạn không thể đề xuất một Hướng dẫn phong cách?

Trên thực tế, đó dường như là những gì bạn muốn làm: bạn tin vào giá trị của hướng dẫn phong cách, bạn đánh giá cao sự nhất quán và bạn muốn truyền giáo cho sự cống hiến cho các hướng dẫn phong cách thống nhất.

Điều đó tốt, miễn là bạn thực sự rõ ràng đó là những gì bạn muốn và những gì bạn muốn thực hiện. Nếu bạn tin vào một Hướng dẫn phong cách cụ thể và tin rằng đó là Hướng dẫn về phong cách đích thực, hoặc ít nhất là tốt hơn bất cứ điều gì những kẻ ngoại đạo vô pháp đang chạy xung quanh thực hành, thì điều đó cũng tốt.

Nhưng những gì mọi người không đánh giá cao được nói rằng hành vi của họ không tuân thủ các quy tắc không chính thức, không ràng buộc, chủ yếu là từ một nguồn mà họ không coi là một cơ quan hợp pháp. Khi đó là những gì bạn đặt ra để làm, hoặc nếu chỉ đơn thuần đó là những gì bạn đang nhận thức được thực hiện, bạn sẽ nhận được ít "điều trị thảm đỏ", và nhiều hơn nữa của các "thổ dân nổi giận với spears và một nồi sôi lớn" điều trị.

Để đưa ra một ý kiến ​​thay thế ở đây, trong nhiều trường hợp, một sự thay đổi như vậy sẽ được hoan nghênh. Các dự án nguồn mở có xu hướng có nhiều tác giả. Thường không có "phong cách mã hóa"; phong cách chỉ là bất cứ điều gì mà người viết mã trong câu hỏi tình cờ sử dụng. Nếu một tập tin được viết bởi một người khác với một người khác, phong cách cũng có thể khác. Ngay cả trong các dự án có phong cách đồng thuận, trừ khi họ kiểm tra phong cách này thường xuyên, nó thường không được sử dụng.

Một ví dụ phổ biến về điều này theo kinh nghiệm của tôi là khi ai đó đóng góp một số mã thông qua yêu cầu kéo có chất lượng tương đối thấp. Tuy nhiên, mã có thể hoạt động. Những người khác nhau có quan điểm khác nhau về điều này. Một số người sẽ từ chối hợp nhất một yêu cầu kéo trừ khi phong cách là tốt. Một số người không quan tâm, miễn là mã hoạt động. Một số người thích có phong cách tốt, nhưng họ không muốn làm mất lòng những người đóng góp bằng một loạt các bình luận "sửa khoảng trắng ở đây" (cá nhân tôi luôn cảm thấy có chút tội lỗi khi đưa ra những bình luận này, mặc dù tôi biết rằng họ tốt hơn tốt của codebase, bởi vì nó cảm thấy như nó có thể khiến người đóng góp sợ hãi).

Vì vậy, đừng cho rằng phong cách mà bạn thấy là phong cách mà dự án muốn. Trong thực tế, điều đó có thể có thể được khái quát để đóng góp cho nguồn mở nói chung: đừng cho rằng mã mà dự án nguồn mở có là mã mà nó muốn .

Bạn nên biết một số điều, mặc dù:

• Một số người tôn giáo về phong cách. Nếu nó trở nên rõ ràng rằng họ không muốn nhúc nhích, thì đừng bận tâm.

• Đây là một khổng lồ bikeshed vấn đề. Mọi người và anh trai của họ có ý kiến ​​về những điều này. Nhận được một yêu cầu kéo như vậy sáp nhập có thể khó khăn vì điều này.

• Cũng có thể khó có được yêu cầu kéo như vậy được hợp nhất bởi vì nó sẽ nhận được xung đột hợp nhất rất nhanh; về cơ bản bất cứ khi nào bất kỳ phần nào của cơ sở mã mà bạn đã sửa đổi đều thay đổi, ngay cả khi nó theo những cách tầm thường.

Tôi sẽ gắn bó với phương pháp "hỏi trước". Nếu họ cởi mở với nó, và bạn sẵn sàng gắn bó với yêu cầu kéo để hoàn thành, thì hãy tiếp tục.

Tôi đã từng rất giỏi trong việc có một hướng dẫn viên phong cách tốt, nhưng với tình trạng của Ruby, "Tôi đã tiếp tục".

Về cơ bản, tôi sống với những gì tôi đang làm việc và tuân theo các quy ước chung mà tôi đã học được từ một số công việc.

Đối với Ruby, ngôn ngữ mà tôi lựa chọn, tôi cũng (trong đầu) chia phong cách thành phổ biến được chấp nhận, thường được chấp nhận, sở thích và thực tiễn tốt nhất của tôi. Những điều được chấp nhận phổ biến Tôi có thể gửi thay đổi như một phần của yêu cầu thay đổi đối với một vấn đề hoặc yêu cầu chi nhánh tính năng.

Ví dụ về mỗi phong cách (theo ý kiến ​​của tôi):

Toàn cầu chấp nhận cho Ruby:

• khoảng trắng không phải là tab
• hai chỗ lõm
• method_names_use_underscores
• Hằng số bắt đầu bằng Caps.

Thường được chấp nhận:

• Không sử dụng dấu ngoặc đơn nếu không cần thiết
• Sử dụng { }cho các khối một dòng và do endcho các khối nhiều dòng.
• CONSTANTS_ARE_IN_ALL_CAPS
• Sử dụng các câu lệnh dự đoán ( cond ? true : false) if thennếu biểu thức phù hợp trên 1 dòng.

Sở thích cá nhân:

• Độ dài dòng 120 ký tự
• whenbáo cáo trường hợp được thụt lề 2 từ báo cáo trường hợp.
• Sử dụng dấu ngoặc đơn trừ khi cần gấp đôi.

Không thỏa thuận:

• Báo cáo trường hợp
• Độ dài dòng

Thực hành tốt nhất:

• phương pháp nhỏ, <= 5 dòng nếu có thể.
• các lớp nhỏ, <= 100 dòng nếu có thể.
• Tránh hằng số
• Mã có các bài kiểm tra

Cuối cùng, như những người khác đã chi tiết, bạn nên hỏi trước. Vào cuối ngày, chìa khóa cho phong cách là giao tiếp giữa các nhà phát triển và nhạy cảm với người khác. Ví dụ: nếu tôi muốn thực hiện thay đổi kiểu trên một dự án nguồn mở, tôi sẽ thường thực hiện yêu cầu kéo đối với một hoặc hai tính năng thực tế hoặc sửa lỗi trước. Khi nhà duy trì biết tôi và thấy rằng tôi đã đóng góp, sau đó tôi có thể đề nghị thay đổi phong cách. Tôi chỉ đề nghị họ mặc dù. Ví dụ: "Trong khi thực hiện một tính năng khác trên dự án x, tôi nhận thấy rằng bạn có 4 dấu cách không gian trong một vài tệp và tôi tự hỏi liệu tôi có thể thay đổi chúng thành 2 không?"

Mặc dù chúng nhỏ và dễ sửa, nhưng bạn có nghĩ thay đổi phong cách mã hóa của một dự án nguồn mở bằng cách sửa các vi phạm và thực hiện Yêu cầu Kéo không?

Tóm lại là không!

Tất nhiên, tôi giả sử ở đây rằng đây chỉ là vấn đề về phong cách và không phải là lỗi thực tế - các yêu cầu kéo cho cái sau sẽ luôn hợp lý (IMO.) Tôi cũng cho rằng bạn là người xa lạ với dự án và không liên lạc với những người duy trì nó.

Tuy nhiên, trong số bất kỳ ngôn ngữ nào, luôn có một số người có sở thích khác với hướng dẫn về phong cách, tốt hơn hoặc xấu hơn và cố gắng thực thi những thay đổi về phong cách đó đối với những người bạn không biết và một dự án mà bạn không tham gia của nếu không có gì khác có thể đi qua như là một chút thô lỗ. Rốt cuộc - bạn đang đạt được điều gì (trong thực tế) nếu yêu cầu được chấp nhận? Rất có thể, nếu các thành viên của một dự án muốn thay đổi phong cách sang một thứ khác, thì họ đã thực hiện nó rồi - và tất cả những gì bạn đang làm với yêu cầu đó là buộc một phong cách đối với họ không nhất thiết phải hoạt động tốt hơn cho các thành viên hiện có.

Điều này thay đổi một chút nếu bạn sẵn sàng đóng góp cho dự án theo những cách khác ngoài cách thực hiện "sửa lỗi". Tôi muốn nói nếu bạn muốn mở một cuộc đối thoại với các nhà bảo trì về cách bạn muốn làm việc trong dự án nhưng tìm một phong cách không chuẩn, thì điều đó tốt. Nhưng tôi thực sự sẽ không đi xung quanh một cách mù quáng tạo ra các yêu cầu kéo cho một loạt các dự án chỉ chứa thay đổi phong cách!

BẤT K change thay đổi nào chịu trách nhiệm giới thiệu các lỗi, thậm chí thay đổi hình thức đánh máy của mã.
Do đó, không có thay đổi nào được thực hiện trên mã trừ khi có trường hợp kinh doanh hợp lệ và "nhưng mã không đẹp" hoặc "mã không tuân theo các tiêu chuẩn mã hóa" không phải là trường hợp kinh doanh hợp lệ. Rủi ro đơn giản là quá lớn.
Bây giờ, nếu bạn đang thực hiện các thay đổi lớn đối với tệp nguồn, thì việc kéo toàn bộ tệp theo các tiêu chuẩn có thể được chấp nhận, nhưng rất có thể bạn sẽ thực hiện các thay đổi nhỏ trong trường hợp gần như phổ biến hơn là giữ các thay đổi của riêng bạn phù hợp với mã hiện tại mặc dù mã hiện tại không tuân theo các tiêu chuẩn mã hóa.
Heck, mã cũng có thể là kết quả của một trình tạo mã và đôi khi được tạo lại. Các trình tạo mã nổi tiếng với việc tạo ra các mã xấu xí ...

Tôi có một vài dự án .NET thành công vừa phải và tôi đã có một vài PR từ những người dường như đã trải qua mã với ReSharper và StyleCop và "sửa" một loạt các công cụ. Tôi không chấp nhận những PR đó, vì một vài lý do:

• Trong khi nhiều thay đổi là tốt hơn, một số trong số chúng tác động tiêu cực đến mã theo một cách nào đó, thường là hiệu suất và chọn những phần tốt là quá nhiều công việc khó khăn.
• Ngay cả khi tất cả các thay đổi là lành tính hoặc thậm chí có lợi, mọi thay đổi trong mọi tệp trong mọi cam kết đều cần được xem xét và một lần nữa, nó chỉ mất quá nhiều thời gian.

Điều đó nói rằng, nếu bất cứ ai muốn thêm một số kiểm tra lỗi hoặc nhận xét tài liệu tốt hơn, tôi sẽ chấp nhận PR đó trong tích tắc.

Bạn cần tìm hiểu xem các nhà bảo trì coi các kiểu mã hóa này có lỗi hay không, hoặc nếu dự án có một tiêu chuẩn khác cho kiểu mã hóa.

Nếu nó có một tiêu chuẩn khác, bạn có thể đề nghị giúp đỡ tài liệu hoặc chính thức hóa nó. Sau đó, nó có thể có một số vi phạm phong cách đó, và bạn có thể sửa chúng.