Nhận xét hài hước có phải là một thực hành xấu hay không? [đóng cửa]

Tôi muốn hỏi bạn liệu việc thêm một số "trứng Phục sinh" trong tài liệu nguồn là không chuyên nghiệp hay không. Có lẽ bạn có đọc StackOverflow thăm dò để lấy ý kiến hài hước trong một tài liệu nguồn, và tôi đã đích thân vấp vào nhiều thứ như vậy trong công việc của tôi, trong đó có hài hước (hoặc không) nội dung trong tài liệu API công cộng (ví dụ yếu này BZZZTT !! 1! Điều trong tài liệu công khai của Android, tôi có thể đưa ra ít nhất một tá ví dụ nữa).

Tôi không thể đi đến một ý kiến ​​cuối cùng cho chính mình, bởi vì tôi đã mâu thuẫn với chính mình.

Đối số chuyên nghiệp:

• Nó có thể cổ vũ ai đó, và làm cho ngày của anh ấy / cô ấy vui hơn / hiệu quả hơn. Phần chính của mã nguồn dù sao cũng không cần phải nhận xét (nếu dự án được thực hiện đúng cách), bởi vì phương pháp cụ thể (ví dụ) là tự giải thích hoặc nếu đó là một đống mã crappy lạ, thì không thể được giải thích một cách có ý nghĩa, vì vậy một trò đùa vui không làm hại thông tin có thể có mà bạn có thể nhận được từ tài liệu.

Nhược điểm:

• Nếu bạn rất tập trung / bực bội, điều cuối cùng bạn cần là trò đùa ngu ngốc của ai đó, thay vì cung cấp cho bạn thông tin bạn cần về phần mã tài liệu, nó có thể khiến bạn thất vọng hơn nữa. Và ý tưởng về tài liệu sẽ như thế nào nếu mọi người bắt đầu làm như vậy thật kinh khủng. Thêm vào đó, anh chàng viết truyện cười có thể là người duy nhất nghĩ rằng thật buồn cười / thú vị / đáng để lãng phí thời gian để đọc nó.

Bạn nghĩ sao?

Tôi nghĩ rằng những bình luận hài hước lãng phí thời gian - lãng phí thời gian để viết, lãng phí thời gian để đọc, lãng phí thời gian để cho các đồng nghiệp của bạn nhận xét hài hước mà (hầu như luôn luôn) chỉ là khó hiểu và vân vân.

Nhưng ... không ai thực sự làm việc 100% cả ngày mỗi ngày (các trang web như thế này sẽ trống nếu chúng tôi làm) và sự hài hước thực sự phá vỡ ngày và giúp duy trì tinh thần.

Tôi vẫn sẽ bỏ phiếu chống lại nó đơn giản bởi vì mọi bình luận 'hài hước' mà tôi từng đọc có thể rất vui nhộn vào thời điểm đó - nhưng tôi vẫn chưa thấy một bình luận nào thực sự hài hước, hầu hết chỉ là khó hiểu hoặc sâu sắc -joke.

Nếu những bình luận hài hước thực sự hài hước thì nó sẽ thay đổi suy nghĩ của tôi. Nhưng một khi bạn khuyến khích những trò đùa, bạn có khuyến khích chửi thề hay lăng mạ hay ác ý không?

Tôi là một fan hâm mộ lớn của bình luận hài hước .

Bạn nên luôn luôn chuyên nghiệp trong việc bình luận, nhưng một số sự hài hước sẽ không giết chết người đọc.

Đặc biệt nếu người đọc là một thành viên trong nhóm của bạn.

Điều tôi không thích nhất, là các nhà phát triển quá coi trọng bản thân họ. Tôi nghĩ chúng ta nên vui vẻ trong công việc, hoặc công việc không xứng đáng.

Nếu nó có ý nghĩa, thật tốt để trở nên hài hước. Giải thích một cái gì đó trong một bình luận một cách thú vị là tốt. Tuy nhiên, nếu đó chỉ là một cái gì đó buồn cười và không có giá trị thực sự như một nhận xét, thì điều đó thật khó chịu. Luôn luôn nhớ rằng lý do cho ý kiến ​​là để bảo trì hiệu quả hơn. Hài hước không phải xung đột với điều đó, nhưng có thể nếu không được thực hiện một cách thích hợp.

Mã có nghĩa là để đọc ... nhiều lần.

Có bao nhiêu câu chuyện cười mà bạn biết là buồn cười sau câu nói thứ một trăm?

Bình luận hài hước là tuyệt vời.

• Nó cung cấp một sự rung cảm tích cực cho mã dường như nhàm chán của bạn.
• Nếu bạn có được thời gian chính xác. Nó giải thích tốt hơn nhiều so với một nhận xét nhàm chán thông thường. Theo "thời gian" ở đây tôi có nghĩa là sự liên quan đến mã bên dưới bình luận.
• Mã của bạn sẽ được nhiều người nhớ đến, bởi vì cảm xúc được dành một vị trí tốt hơn trong bộ nhớ (con người). Đây là một mẹo hay nếu bạn muốn nhiều người cùng làm việc với bạn trong một dự án nguồn mở.
• Nói chung là hữu ích trong đánh giá. Nó làm cho mã của bạn dễ chịu hơn rất nhiều. Tất nhiên trước tiên bạn nên tập trung vào viết mã tốt. Tôi cảm thấy khi một người tự tin với mã họ viết, những bình luận hài hước chỉ là một tác dụng phụ.

Đừng buồn cười như anh chàng này ;)

Đây là một cái tôi đã viết lúc hai giờ sáng ("DQ" là tên viết tắt của công ty tôi):

// Twas the night before go-live and all through DQ
// the devs were all crying and yes, this means you.
// Keys had been saved with both hyphens and 'scores
// which left this programmer with finger pad sores.
// The solution I crafted, you'll likely find lacking:
// to OR them together with judicuous hacking.

$hyphenated = str_replace('_','-',$data_type_key);
$underscored = str_replace('-','_',$data_type_key);
// (and then see line 46)

Nếu bạn đang xem xét mã nguồn của mình trước mặt khách hàng, bạn có thấy xấu hổ không?

Không có câu trả lời hiện tại nào có vẻ như tính đến điều đó. Một số khách hàng không có khiếu hài hước và sẽ lấy những câu chuyện cười làm chỉ số cho thấy bạn không coi trọng công việc của mình. Họ sẽ suy luận rằng bạn bất cẩn với công việc của bạn.

Bình luận mã hài hước đôi khi có thể không chuyên nghiệp và không phù hợp.

Ngoài những gì đã nói, nếu bạn làm việc trong nhóm quốc tế, một số đồng nghiệp ở nước ngoài của bạn có thể không đùa, bởi vì một số tài liệu tham khảo văn hóa địa phương hoặc một số từ 'không được hiểu bởi một người mà tiếng Anh không phải là ngôn ngữ mẹ đẻ . Điều tương tự áp dụng cho các dự án nguồn mở.

Nếu nó hiệu quả và không lãng phí thời gian của độc giả (bằng cách đọc / hiểu) thì tôi không thấy có vấn đề gì với một chút hài hước.

Giống như những trò đùa trong thế giới thực, nếu bạn làm chúng mọi lúc thì không hài hước, không hiệu quả và không chuyên nghiệp. Nhưng có một thời gian và địa điểm cho tất cả các trò đùa, và có một thời gian và địa điểm trong mã. Giống như trong thế giới thực, nó biết ở đâu, khi nào và làm thế nào để thực hiện trò đùa.

Phụ thuộc vào các bài tập ở trường đại học, tôi hầu như luôn luôn bình luận hài hước, vì tôi biết nó sẽ không bao giờ được sử dụng và chỉ là một bài tập về nhà.

Đối với các dự án nghiêm trọng hơn, tôi vẫn sử dụng chúng ở đây và ở đó, nhưng không phổ biến, do đó gây khó chịu hoặc khó hiểu, bất chấp mục đích của nhận xét.

Tôi nhớ đã làm một chút về lập trình web, nơi tôi phải tránh sự không tương thích của trình duyệt và những trục trặc kỳ lạ. Nó đôi khi kết thúc trong các bình luận đầy giận dữ và ghét trong các .jstập tin.

Nguyên tắc cơ bản của tôi là: Nếu phần nào đó rõ ràng phần mã làm gì, thì Ý KIẾN BẮT ĐẦU!

Nếu mã quá tối nghĩa và che khuất như địa ngục (như " lớp nội tuyến "), tốt hơn tôi nên sử dụng các nhận xét Tôi sẽ hiểu bản thân mình trong một vài ngày ...