Xử lý thô tục trong mã nguồn [đã đóng]

Làm thế nào để mọi người đối phó với sự thô tục trong mã nguồn và nhận xét VCS. Giữ hay xóa?

Còn những thám hiểm mềm như WTF hay Arrgggh thì sao?

Là không chuyên nghiệp, gây khó chịu hoặc một cái gì đó để nhún vai?

Nó nên được khuyến khích nhẹ nhàng

.. bạn không thể biết ai sẽ xem mã nguồn trong suốt vòng đời của nó.

Mặc dù đó là một phần của công việc khiến bạn nản lòng với một đoạn mã đặc biệt phức tạp hoặc cũ và muốn loại bỏ nó, việc đưa thám hiểm / rants / nghệ thuật ASCII / những câu chuyện dở khóc dở cười / nhận xét xúc phạm vào mã nguồn là không chuyên nghiệp và ý tưởng tồi trong kinh nghiệm của tôi. Đôi khi, kỹ sư viết bình luận không biết gì về hiệu ứng cuối cùng mà bình luận của anh ta có thể có - đây chỉ là một số vấn đề tôi thấy:

• Một số lượng lớn các mã khai thác trong mã được phát hành ra công chúng dưới dạng mã nguồn mở / mã mẫu.
• Truyện cười trong hương vị kém gây ra sự xúc phạm sâu sắc đối với một số thành viên trong nhóm dẫn đến tòa án công nghiệp.
• Những nhận xét vứt đi mà thực sự là phân biệt chủng tộc / phân biệt giới tính / giới tính khiến mọi người bị sa thải.

Mặc dù tất cả chúng ta cần phải có một số cửa hàng cho sự thất vọng / vui vẻ / pha trò, nhưng mã nguồn không phải là nơi để làm điều này, IMO. Bạn sẽ không đặt những lời quảng cáo / trò đùa / bình luận xúc phạm vào Hợp đồng, Trang trợ giúp, Bản thiết kế hoặc tài liệu chuyên môn khác, mặc dù những tài liệu đó có thể được đọc thậm chí ít thường xuyên hơn mã nguồn.

Nếu các nhà lãnh đạo nhóm hết sức nặng nề về điều đó, sẽ rất khó chịu, vì vậy tôi nói 'nhẹ nhàng nản lòng' bằng một từ im lặng với các kỹ sư có vấn đề và cung cấp các cơ chế thông hơi phù hợp để xả hơi, cho dù đó là Facebook, nhắn tin tức thì , khúc côn cầu trên không hoặc túi đấm bốc.

Sẽ không có gì để nói rằng các bình luận được tổng hợp - cả về JavaScript hay bất kỳ mã phía máy khách động nào khác?

Dưới đây là một số trải nghiệm trong thế giới thực mà tôi đã có đã định hình ý kiến ​​của tôi:

• Khi làm việc tại Microsoft, tôi đã phát hiện ra rằng một kỹ sư phần mềm không biết cách viết đúng chính tả của "không thể" - anh ta đã bỏ lỡ chữ o, l và d - và đã viết rất nhiều mã của mình với những lời giải thích dài về cách anh ta không thể bắt X làm việc vì người Y đã gây ra vấn đề Z. Mã của anh ấy rất tuyệt; chính tả của anh ấy không tốt lắm Có thể nói, bất kỳ người xem xét tiếp theo nào của mã này (ví dụ như tôi) đều hoảng hốt khi thấy một số lượng lớn lời thề ngẫu nhiên trong mã. Một số mã này đã được hiển thị cho các đối tác (người viết trình điều khiển). Hãy tưởng tượng nỗi kinh hoàng của họ khi nhìn thấy những lời thề. Các lý thuyết nên được gửi đến người quản lý dự án ở dạng lời nói (trong trường hợp đó người Y có thể được kéo vào cuộc thảo luận) hoặc có thể cam kết thông điệp, nhưng không phải trong nguồn.

• Tại một công ty, một cá nhân nói tiếng nước ngoài đã tham gia một nhóm chủ yếu nói tiếng Anh. Ông viết bình luận bằng ngôn ngữ của mình, nghĩ rằng không ai khác có thể đọc chúng. Điều này vẫn ổn, cho đến khi Babelfish / Google Dịch đưa ra tùy chọn 'sang tiếng Anh' cho ngôn ngữ của mình, lúc đó, phần còn lại của nhóm đã dịch một vài bình luận và kinh hoàng trước những bình luận bẩn thỉu và thường bị chế giễu mà anh chàng đã đưa ra về công ty , đội của anh ấy và một đồng nghiệp nữ. Lúng túng .

• Tại một công ty khác, một anh chàng đã thực sự được chụp bằng nghệ thuật ASCII và đưa tất cả các loại nghệ thuật vào mã nguồn của mình, không được phát hiện (hoặc có lẽ là may mắn) bởi các nhà đánh giá mã. Sau một thời gian, anh ta tập trung vào những con rồng, vì một số lý do, thường là với một số loại thẻ dòng. Sau đó, một người xứ Wales gia nhập đội. Biểu tượng quốc gia của xứ Wales là một con rồng đỏ, vì vậy anh chàng mới ban đầu rất vui về những bức ảnh, nhưng sau đó bị xúc phạm khi một số dòng thẻ ngớ ngẩn có thể được hiểu là gây khó chịu. Có, cần có một số hòa giải trưởng nhóm, nhưng điều này không nên xảy ra.

Tên / chi tiết cụ thể được loại bỏ để bảo vệ người vô tội.

Nếu bạn đang bán mã nguồn của mình (tức là bạn là người viết thành phần), có lẽ nó không nên ở đó.

Nếu đó là vấn đề thận trọng, thì dù sao đi nữa, điều đó tùy thuộc vào bạn.

Nếu bạn thấy ai đó viết nhiều WTF thì có lẽ đó là dấu hiệu bạn nên nói chuyện với họ về những vấn đề mà họ đang gặp phải.

Nếu ai đó đang hướng sự hung hăng của họ vào mã của người khác, thì họ có thể đang quấy rối người đó và bạn có một tình huống hoàn toàn khác để giải quyết. Có lẽ họ có khiếu nại hợp pháp và không biết cách nói đúng. Có lẽ họ chỉ là một thằng ngốc.

Sẽ không khôn ngoan khi chỉ có một số loại bộ lọc nội dung, bất cứ điều gì nhà phát triển viết đều quan trọng và nó cho bạn biết rất nhiều về cách mọi thứ đang diễn ra.

Tôi làm việc cho một công ty Fortune 500 chuyên thiết kế, sản xuất và bán các sản phẩm tiêu dùng có CodeControllers chạy mã được phát triển nội bộ. Kiện tụng luôn là một khả năng, hoặc từ người tiêu dùng hy vọng làm giàu nhanh chóng, hoặc bởi các đối thủ cạnh tranh tuyên bố vi phạm. Vì điều này, chúng tôi viết mã của chúng tôi và TẤT CẢ các bình luận với kiến ​​thức rằng nó có thể (có thể sẽ) xuất hiện dưới sự giám sát của các bồi thẩm viên thù địch vào một lúc nào đó. Điều đó có nghĩa là tên biến và hàm không nên bao gồm các thuật ngữ xúi giục, như KILL_CHILD(int process_id). Mặc dù mục đích của chức năng ví dụ này rất có thể là chấm dứt các quá trình con, làm thế nào một bồi thẩm đoàn thù địch sẽ xem tên hàm đó nếu con của nguyên đơn bị giết trong khi sử dụng sản phẩm?

Nhận xét trong mã có thể còn tồi tệ hơn. Trong khi một đội bảo vệ đàng hoàng có thể có thể xử lý việc giải thích quá trình trẻ em là gì (từ ví dụ trước) và tại sao nó có thể cần phải chấm dứt, thì gần như không thể bảo vệ chống lại một bình luận như:

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

Những bình luận trái chiều như thế đã quyết định các yếu tố trong các vụ kiện ở tòa án thực sự.

Về một chủ đề liên quan, tên cho các dự án cũng có thể gây tổn hại khi dưới kính hiển vi của kiện tụng dữ dội. Bạn có nhớ sự náo động từ các nhóm bảo thủ vào giữa thập niên 90 khi các nguồn tin công nghệ báo cáo "SATAN Unleashed trên Internet" không?

<rant_mode_off>

Với tất cả những gì đã nói, đối với các dự án cá nhân, bạn có thể tự do làm những gì bạn thích trong mã của mình.

Nếu điều đó làm phiền bạn và bạn là người đứng đầu, tôi không hiểu tại sao bạn không thể thực hiện quy tắc về việc này. Bạn là người đứng đầu trong tình huống giả định này.

Tuy nhiên, nếu nó chỉ làm phiền bạn và không ai khác có vẻ để tâm thì có lẽ bạn chỉ nên mút nó.

Tôi có thể không phải là người thích hợp để hỏi vì tôi thường sử dụng những lời tục tĩu nhẹ.

Tôi nghĩ rằng nó chủ yếu phụ thuộc vào cách PC (Chính trị chính xác) môi trường của bạn.

Nếu tôi viết mã cho một công ty phù hợp, tôi sẽ cố gắng không sử dụng thô tục nhưng nếu đó là cho một dự án sở thích hoặc một cái gì đó tôi có xu hướng nói lên suy nghĩ của tôi một cách tự do hơn.

Dường như với tôi rằng ở Hoa Kỳ và một số quốc gia khác, người ta sử dụng nhiều PC (hoặc bị kẹt) hơn ở Hà Lan nơi tôi sống và làm việc.

Là một phần thưởng bổ sung, đây là một số thống kê về sự thô tục trong mã: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-lingu/

Tôi có khuynh hướng đồng ý rằng nó có thể không chuyên nghiệp, nhưng mọi người thỉnh thoảng lại chửi rủa nên tôi cố gắng không chống lại người khác. Điều đó nói rằng, cơ sở mã hóa có xu hướng phản ánh tính chuyên nghiệp chung của nhóm, vì vậy một cơ sở mã hóa đầy tính khám phá có thể phản ánh một nhóm không chuyên nghiệp và một cuộc họp có thể cần phải "áp dụng một số đánh bóng" cho nhóm. Tương tự, nếu một số xu hướng nhất định xuất hiện trong mã, nó có thể là một chỉ báo cho các vấn đề chung trong nhóm cần được giải quyết (tức là API bạn đang làm việc có vấn đề khiến các nhà phát triển nản lòng).

Về mặt cơ sở mã, tôi thường chỉ cần chỉnh sửa nhận xét có liên quan để an toàn cho công việc và để nó ở đó. Tùy thuộc vào ngôn ngữ bạn đang làm việc, đây luôn là một ý tưởng hay vì bạn không bao giờ biết những gì có thể xuất hiện trước mặt khách hàng hoặc khách hàng.

Đây có phải là không chuyên nghiệp, gây khó chịu hoặc một cái gì đó để nhún vai?

Có thể cả ba ... tùy theo quan điểm của bạn.

Bản chất của con người là mọi người thể hiện bản thân bằng cách sử dụng "ngôn ngữ đầy màu sắc" trong một số tình huống. Nhiều hơn trong một số nền văn hóa hơn ở những nền văn hóa khác, và một số người nhiều hơn những nền văn hóa khác. Nhưng xu hướng là phổ quát.

Nếu tôi là bạn, tôi sẽ nhún vai trừ khi bạn sẵn sàng khiến bản thân không được lòng bạn bè.

Tuy nhiên, nếu các nhận xét về mã nguồn / VCS được công bố bên ngoài tổ chức của bạn, ban quản lý của bạn có thể muốn đưa ra một dòng mạnh mẽ hơn, trên cơ sở rằng việc doanh nghiệp xúc phạm khách hàng của bạn là điều không tốt.

Một trong những vấn đề thô tục là nó khác với văn hóa. Ở Mỹ, những thứ vô tội có xu hướng bị "tuôn ra", trong khi ở các quốc gia khác, bạn thường có thể nghe thấy cùng một ngôn ngữ được trao đổi trong các cuộc thảo luận của quốc hội.

Sự thô tục trong mã và nhận xét cam kết là khá phổ biến, có thể là do quan điểm "không ai sẽ thấy nó". Tôi nghĩ rằng nó thực sự phổ biến hơn bây giờ khi hầu hết các tổ chức ngoài vòng trứng Phục sinh.

Cá nhân tôi nghĩ rằng những thứ không phải là khách hàng phải đối mặt (như tài liệu cam kết nội bộ) không phải là vấn đề lớn.

Tuy nhiên, hầu hết các công ty đa quốc gia lớn được điều hành bởi các bộ phận pháp lý và "nơi làm việc an toàn" và tất cả những thứ đó, điều đó có nghĩa là bất cứ điều gì có thể gây khó chịu cho ít nhất một người là một vấn đề và nguyên nhân tiềm ẩn cho việc sa thải. Tôi ghét phải thừa nhận nó, nhưng tôi có xu hướng cúi đầu trước các quy định của những người trả lương cho tôi.

Một giải pháp nhanh chóng cho vấn đề này là cài đặt bộ lọc thô tục trên hệ thống kiểm soát nguồn của bạn (dưới dạng tập lệnh phát hành trước hoặc kiểm tra thường xuyên).

Tôi nghĩ rằng nó ổn miễn là nó không nằm ngoài tầm kiểm soát như thả bom xuống đó. Tôi đã thấy một anh chàng làm việc cùng tôi viết kịch bản giữa hai nhân vật thảo luận về các đối tượng khác nhau mà họ đại diện. Có một bình luận đa dòng chạy trong khoảng 30 dòng của hai nhân vật này nói chuyện qua lại với nhau.

/ * * igor: tôi có nên biến mình thành masster công khai không? * Frankenstein: ah igor, tôi sẽ thừa hưởng từ những đặc điểm tốt nhất của bạn ... * /

Nó đã diễn ra như thế trong một thời gian dài. Anh ta đã tạo ra hai vật thể được gọi, bạn đoán nó: Frankenstein và Igor là một phần của việc kiểm tra sự tỉnh táo. Nó thực sự rất sáng tạo nhưng hoàn toàn lãng phí thời gian. Tôi thà nhìn thấy một vài WTF hoặc thám hiểm hơn là một kịch bản giữa hai đối tượng C # ...

Phụ thuộc vào văn hóa của công ty / khách hàng. Ví dụ, nếu bạn đang phát triển phần mềm Kinh Thánh, các thám hiểm dưới mọi hình thức chắc chắn không được chào đón. Mặt khác, một nhà phát triển trò chơi có thể không quan tâm lắm (hoặc đi đến cực đoan khác).

Tôi luôn tâm niệm rằng mọi bình luận (bằng mã hoặc cam kết) sẽ hữu ích . Một số từ thu hút sự chú ý của chúng tôi nhiều hơn những từ khác - thám hiểm, thậm chí đa dạng mềm, chắc chắn được chú ý. Nó có thể hữu ích để gọi sự chú ý đến một cái gì đó hoàn toàn sai nhưng bạn không có cách nào xung quanh nó.

Điều đó nói rằng, tôi không sử dụng thám hiểm nhưng đôi khi tôi sẽ sử dụng những thứ như "Doh!" hoặc "Hả?" Điều đó không quá khác biệt về tinh thần. Nếu điều đó làm phiền bạn, hãy nói về điều đó với người phạm tội - anh ấy có thể không nghĩ về điều đó. Nếu họ bảo bạn đi lang thang và bạn cảm thấy mạnh mẽ về điều đó, hãy đến gặp người quản lý. Nếu bạn không nhận được sự hỗ trợ từ người quản lý, thì bạn sẽ phải học cách sống với nó hoặc đi nơi khác.

Chà, tôi không chắc chính xác những gì bạn muốn nói về mã như thế này:

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

Mã này được lấy từ một cơ sở mã thực sự cực kỳ tồi tệ mà tôi đã cố gắng tối ưu hóa gần đây. (Mã này là nguồn mở, vì vậy tôi không tiết lộ bất kỳ bí mật nào của nhà tuyển dụng ở đây hoặc bất cứ điều gì.)

Như những người khác đã nói, nó phụ thuộc vào nơi làm việc và ai sẽ xem mã nguồn.

Nếu tôi đang bán mã nguồn, tôi sẽ có một kho lưu trữ thứ hai chỉ có các phiên bản được phát hành và không cho phép bất kỳ nhận xét đăng ký nào trong đó ngoài mô tả về những gì mỗi phiên bản mới cung cấp. Những gì tôi làm hàng ngày và tất cả những sai lầm của tôi là giữa tôi và nhóm của tôi, không phải khách hàng của tôi.

Hiện tại máy chủ xây dựng của tôi báo cáo về các bình luận OMG, WTF, kydge, mess và TODO như là một số liệu dọn dẹp còn lại để thực hiện ngay bây giờ chúng là một phần của quy trình.

Nếu bạn thấy thô tục trong phần mềm nguồn mở và muốn thoát khỏi nó, hãy chuẩn bị cho khả năng đẩy lùi. Đừng chỉ viết một báo cáo lỗi ba dòng và mong muốn nó được chấp nhận. Viết một bài tiểu luận giải thích tại sao ngôn ngữ thô tục và phân biệt đối xử là xấu, và trước những lời phản bác.

Tôi nghĩ đó là vấn đề sở thích cá nhân. Những thứ đó không thực sự làm phiền tôi, vì vậy tôi có thể sẽ rời bỏ nó. Thậm chí có thể cho tôi một gợi ý về nơi các khu vực có vấn đề trong mã.

Họ có làm phiền bạn không? Từ thực tế là bạn đang hỏi câu hỏi này, tôi đoán rằng họ làm. Trong trường hợp đó, loại bỏ chúng hoặc làm sạch chúng thành những nhận xét phù hợp hơn về những gì sai.