Ruby: Phần xấu [đã đóng]

Gần đây tôi đã đọc cuốn sách "Javascript: Bộ phận tốt" của Crockford và một trong những tiền đề cơ bản là ngôn ngữ lập trình có thể có các bộ tính năng xấu mà các lập trình viên nên tránh.

Tôi là một người theo chủ nghĩa Ruby và trong khi tôi yêu ngôn ngữ thì luôn có giá trị trong việc có được viễn cảnh. Vậy, bạn thấy tính năng nào tệ nhất (ví dụ: phương thức, lớp học, thực tiễn) trong Ruby? Ý định của tôi ở đây không phải là bắt đầu một cuộc tranh luận về giá trị của ngôn ngữ hay tốc độ của nó, v.v. Thay vào đó, tôi thích thảo luận về những tính năng mà bạn cho là nguy hiểm / rắc rối / đau đớn khi sử dụng, dựa trên kinh nghiệm trong quá khứ.

Bạn nên xem Python vs Ruby: A Battle to The Death của Gary Bernhardt. Ông đưa ra trích dẫn:

Chính những điều tôi thấy xấu xí ở Ruby là những gì làm cho phần mềm Ruby tuyệt vời như RSpec trở nên khả thi và Python không bao giờ có thể có được (với cách triển khai hiện tại).

Trong khi anh ấy nói rất nhiều về Python nói riêng, anh ấy đã chạm vào rất nhiều thứ kỳ lạ ở Ruby. Một trong những chủ đề bao trùm lớn là vá khỉ .

Các đối tượng Ruby (không giống như các đối tượng trong một số ngôn ngữ hướng đối tượng khác) có thể được sửa đổi riêng lẻ. Bạn luôn có thể thêm các phương thức trên cơ sở từng đối tượng. Trong Ruby, hành vi hoặc khả năng của một đối tượng có thể đi chệch khỏi những thứ được cung cấp bởi lớp của nó.

Mặc dù điều này cung cấp rất nhiều tính linh hoạt và tăng sức mạnh cho một số loại đá quý phổ biến và phức tạp nhất của Ruby, nó có thể cắn vào mông bạn nếu bạn đang cố gắng gỡ lỗi một vấn đề mà không nhận ra rằng một số thư viện ở đâu đó đã sửa đổi một phương pháp cốt lõi.

Một số người chỉ nghĩ về ruby ​​về mặt ruby ​​trên đường ray và điều đó hơi khó chịu vì ngôn ngữ này tự nó khá tốt.

Tôi nghĩ rằng tính năng tồi tệ nhất là open classescho phép bạn thay đổi toàn cầu hành vi của tất cả các trường hợp hiện tại và tương lai của lớp đã thay đổi.

Phần có vấn đề của tính năng này là, những thay đổi (toàn cầu) xảy ra trong thời gian chạy khi trình thông dịch Ruby xuất hiện định nghĩa, có thể rất lâu sau khi bạn đã khởi tạo một vài đối tượng đột nhiên thay đổi hành vi của chúng.

Trong một cơ sở mã lớn, điều này có thể dẫn đến các lỗi rất, rất khó tìm thấy - đặc biệt là khi điều này được kết hợp bởi câu chuyện gỡ lỗi yếu của Ruby (ví dụ như câu chuyện gỡ lỗi CLR hoặc JVM) và sử dụng các tính năng khác (ví dụ eval) trong ngữ cảnh này có thể tạo ra khá khó để tìm vị trí xảy ra sự thay đổi toàn cầu này. tức là nếu bạn đã đạt đến điểm mà bạn nghi ngờ lớp 'đúng' gây rắc rối! Theo kinh nghiệm của tôi, bạn thường bắt đầu với một cuộc săn đuổi ngỗng hoang dã, vì các vấn đề bắt đầu nổi lên ở một đối tượng sử dụng thủ phạm thực sự.

Vì vậy, điều tốt nhất là, hoặc ngừng sử dụng các lớp mở ( #extendvà đặt các thay đổi trong một Modulelà IMHO an toàn hơn, dễ hiểu hơn và tốt hơn để kiểm tra) hoặc nếu không thể tránh được:

• chỉ mở rộng các lớp với hành vi mới (tức là không ghi đè hành vi hiện có)
• có một vị trí được xác định trong cây mã nguồn, nơi tất cả các phần mở rộng sử dụng các lớp mở phải được đặt
• không sử dụng #evalvà bạn bè để tạo các lớp mở
• đặt tất cả các tập quán của các lớp mở lên một biểu đồ lớn có thể nhìn thấy, nơi tất cả các nhà phát triển có thể nhìn thấy chúng - và làm rõ rằng mọi thay đổi trên chúng là 'quyết định kiến ​​trúc' ảnh hưởng đến toàn bộ cơ sở mã (mà chúng làm) và không phải là nơi để hack nhanh cho nhiệm vụ hiện tại của bạn

Lý do lớn nhất tôi không sử dụng Ruby: Nó chậm hơn mật đường vào tháng 1 ở Bắc Cực trong thời kỳ băng hà. Ngôn ngữ điểm chuẩn là một khoa học không chính xác, nhưng Ruby xuất hiện chậm hơn nhiều so với JavaScript và Python.

Nếu điều này có thể được mở rộng thành Ruby on Rails, thì:

1. Thực tế là logic cơ sở dữ liệu cung cấp cho mỗi bảng một auto_incrementkhóa chính, bao gồm các bảng không cần chúng và không nên có chúng.

2. Thực tế là các phím ghép không được hỗ trợ.

Đối với Ruby đơn giản, sự kìm kẹp của tôi sẽ giống như với bất kỳ ngôn ngữ nào đánh đổi sự an toàn cho tính biểu cảm; Thật dễ dàng để làm rất nhiều chỉ với một ít mã, nhưng thật dễ dàng để tạo ra một mớ hỗn độn lớn với bất kỳ số lượng mã nào.

Ruby chấp nhận siêu lập trình (phản xạ, hướng nội), lập trình đa mô hình và tính năng động ở mức độ không phổ biến. Thật dễ dàng để tự bắn vào chân mình bằng sức mạnh và sự linh hoạt.

Khó khăn? Ruby có khả năng cực kỳ dễ đọc hoặc không thể phá vỡ. Tôi đã thấy mã trông giống như trong tập lệnh Bash.

Thực tiễn xấu? Một số Rubyist coi trọng sự thông minh hơn trí tuệ. Họ viết và chia sẻ các thủ thuật thể hiện sự thông minh của họ, nhưng điều này tạo ra mã không thể đọc được và dễ vỡ.

Bên cạnh đó: Javascript là một thảm họa bởi thiết kế và cuốn sách "Những phần tốt" cố gắng lấy ra vẻ đẹp tiềm ẩn của nó. Perl, một ngôn ngữ phổ biến "Có nhiều cách để làm điều đó" (nghĩa là linh hoạt), có một cuốn sách tương tự trong "Perl, Thực tiễn tốt nhất". Lịch sử của Perl là một trong những thử nghiệm và kinh nghiệm khó thắng, "Thực tiễn tốt nhất" đại diện cho kiến ​​thức của nó. Perl 6 sẽ, tôi nghĩ thật công bằng khi nói, việc khởi động lại ngôn ngữ dựa trên kiến ​​thức đó và hơn thế nữa. Ruby có thể bị các vấn đề tương tự.

@James và cho các vòng lặp ... Khi bạn thực hiện một vòng lặp for trong ruby, nó sẽ gọi ".each". Do đó, "for" là đường cú pháp giúp mọi người thoải mái hơn với các vòng lặp kiểu C. Nhưng là một Rubyist, bạn sẽ sử dụng các trình vòng lặp như .map, .inject, .each_with_object, mọi lúc. Bạn sẽ không bao giờ phải viết một vòng lặp for với nội dung như "i = 0; i> 6; i ++" bằng ruby, và vì vậy cuối cùng bạn đã bỏ thói quen này. @andrew ... ruby ​​hùng hồn không chứng thực cho các vòng lặp.

Đây là về các lập trình viên nhiều hơn ngôn ngữ, nhưng tại sao các lập trình viên Ruby ghét các vòng lặp quá nhiều?

Tôi nhận ra Ruby có:

someCollection.each do |item|
   ...
end

nhưng tôi chưa bao giờ thấy rằng được sử dụng trong các tình huống trong đó một vòng lặp for sẽ không thực hiện chính xác điều tương tự.

Tôi đã hỏi nhiều lần và không bao giờ nhận được câu trả lời hay cho câu hỏi này.

Nếu đó chỉ là một phong cách, tôi rất vui khi chấp nhận điều đó, nhưng tôi đã thấy các lập trình viên Ruby thực sự làm việc về điều này và tôi thực sự tò mò.

Nói chung, tôi nên tránh những thứ được thêm vào để tương thích ngược với các ngôn ngữ khác. Ví dụ, Perlism và for x in y.