Tại sao việc viết một cái gì đó bằng ngôn ngữ X lại tệ như thể bạn đang viết một chương trình bằng ngôn ngữ Y về việc sử dụng mô hình mã hóa được chia sẻ [đóng]


25

Cách đây một thời gian, tôi đã hỏi một câu hỏi trên SO về một cái gì đó được viết bằng C ++, nhưng thay vì nhận được câu trả lời cho vấn đề này, các ý kiến ​​đã phát điên lên theo phong cách mã hóa của tôi, ngay cả khi tôi chỉ ra rằng đó là một đoạn mã WIP và rằng tôi có nghĩa là để làm sạch nó sau này khi tôi có trường hợp cơ sở đang chạy. (Tôi đã nhận được rất nhiều phiếu bầu xuống và tôi đã quyết định rút câu hỏi, vì đại diện của tôi trên SO đã gần hết rồi)

Nó làm cho tôi tự hỏi tại sao mọi người chấp nhận một thái độ cứng rắn như vậy "bạn là một người không biết nói, hãy tự đi". Tôi đã bị buộc tội viết C ++ như thể đó là Java. Một cái gì đó mà tôi không thể hiểu, và điều đó vẫn gây trở ngại cho tôi.

Tôi đã lập trình bằng một vài ngôn ngữ OOP trong một số năm nay, mặc dù trong các khoảng thời gian. Tôi chọn ngôn ngữ để sử dụng theo các thư viện có sẵn và môi trường thực thi tối ưu cho công việc hiện tại. Tôi chấp nhận các mẫu thiết kế trong mã OOP và tôi khá tự tin rằng việc sử dụng các mẫu của tôi là âm thanh và OO khôn ngoan, tôi có thể giữ riêng mình. Tôi hiểu hộp công cụ OOP, nhưng chọn chỉ sử dụng các công cụ khi tôi nghĩ rằng nó thực sự cần thiết, không chỉ sử dụng một thủ thuật gọn gàng để hiển thị trí thông minh mã hóa của tôi. (Điều mà tôi biết không phải là đỉnh cao, nhưng tôi nghĩ cũng không ở mức n00b).

Tôi thiết kế mã của mình trước khi tôi viết một dòng duy nhất. Để xác định các bài kiểm tra, tôi liệt kê các mục tiêu của một lớp nhất định và các tiêu chí kiểm tra mà nó phải tuân thủ. Vì việc tạo sơ đồ tuần tự dễ dàng hơn và sau đó viết mã, tôi đã chọn viết các bài kiểm tra của mình sau khi giao diện trở nên rõ ràng.

Tôi phải thừa nhận rằng trong đoạn mã tôi đã đăng trong câu hỏi, tôi vẫn đang sử dụng con trỏ, thay vì sử dụng con trỏ thông minh. Tôi sử dụng RAII bất cứ khi nào tôi có thể. Tôi biết RAII thích hợp có nghĩa là bảo vệ chống lại nullpointers, nhưng tôi làm việc tăng dần. Đó là một công việc đang tiến triển và tôi có nghĩa là để làm sạch nó sau. Cách làm việc này đã bị lên án mạnh mẽ.

Theo quan điểm của tôi, tôi nên có một ví dụ hoạt động trước để tôi có thể xem liệu trường hợp cơ sở có phải là một cách suy nghĩ khả thi hay không. Tôi cũng tình cờ nghĩ rằng việc làm sạch mã là một cái gì đó điển hình cho giai đoạn tái cấu trúc của agile, sau khi trường hợp cơ sở đã được chứng minh. Tôi phải thừa nhận rằng mặc dù tôi đang dần đạt được tiêu chuẩn Cxx, tôi thích sử dụng những gì tôi hiểu, thay vì mạo hiểm sử dụng các khái niệm mà tôi chưa nắm vững trong mã sản xuất. Thỉnh thoảng tôi thử những thứ mới, nhưng thường trong các dự án chơi mà tôi có ở bên, chỉ với mục đích đó.

[sửa] Tôi muốn làm rõ rằng đề xuất của gnat [1] đã không xuất hiện trong tìm kiếm tôi đã làm trước khi tôi bắt đầu đặt câu hỏi của mình. Tuy nhiên, mặc dù đề nghị của anh ấy không bao gồm một khía cạnh của câu hỏi, câu hỏi mà anh ấy liên kết không trả lời được câu hỏi của tôi, chỉ là một phần của câu hỏi. Câu hỏi của tôi là nhiều hơn về phản ứng tôi nhận được cho phong cách mã hóa của mình và các khía cạnh chuyên nghiệp trong việc xử lý các phong cách mã hóa khác nhau và mức độ kỹ năng (rõ ràng). Với câu hỏi trước đây của tôi về SO và đây là câu trả lời. [/chỉnh sửa]

Câu hỏi sau đó là: tại sao lại chế giễu ai đó không sử dụng phong cách mã hóa của bạn?

Các vấn đề / phân khu trong tay đối với tôi là:

  • Tại sao nó sẽ là một thực tiễn lập trình tồi khi sử dụng mã dễ bị lỗi hơn trong các tình huống nguyên mẫu, nếu việc tái cấu trúc làm cho nó mạnh hơn sau đó?
  • Làm thế nào để chương trình được viết bằng C ++ giống như được viết bằng Java? Điều gì làm cho nó trở thành một chương trình tồi, (xem xét rằng tôi đã chỉ ra ý định của phong cách hiện tại và công việc được lên kế hoạch để cải thiện?)
  • Làm thế nào tôi trở thành một chuyên gia tồi nếu tôi chọn sử dụng một cấu trúc được sử dụng trong một mô hình lập trình nhất định (ví dụ OOP / DP)?

[1] Phát triển nhanh và lỗi, sau đó sửa lỗi hoặc chậm, cẩn thận cho từng dòng mã?


5
Bạn có thể tốt hơn nên hỏi những người trong The C ++ Lounge câu hỏi này. Đặt bộ đồ chống cháy của bạn đầu tiên.
Robert Harvey

48
C ++ folks là một giống khác thường trong số các lập trình viên. Bộ công cụ Java của bạn là một hộp công cụ hợp lý, dễ hiểu với các công cụ quen thuộc trong bao da có đệm sẽ hoạt động trong bất kỳ cửa hàng công cụ nào. C ++ là toàn bộ công cụ với máy cưa, máy khoan điện và một số công cụ không ai nhận ra, tất cả những gì đám đông C ++ có thể xử lý như ninja. Nó làm họ đau khổ khi có ai đó bước vào và đặt một số dụng cụ trở lại kệ không đúng chỗ. Chúng là "số đo hai lần, cắt một lần" của các lập trình viên.
Robert Harvey

13
Có thể đó là phản ứng giống như bạn đối với mã Java được viết như FORTRAN: tất cả mã trong một lớp duy nhất, không có bộ sưu tập, chỉ các mảng có kích thước cố định, với các intbiến riêng biệt để theo dõi độ dài thực tế.
kevin cline

14
Nếu bạn viết C ++ như Java, bạn có thể sẽ phải chịu quá nhiều phân bổ heap, điều này sẽ khiến chương trình của bạn hoạt động kém hơn mức có thể. Các ngôn ngữ có xu hướng được thiết kế và tối ưu hóa để thúc đẩy các mẫu nhất định và nếu bạn phá vỡ các mẫu đó, mọi thứ sẽ có xu hướng trở nên tồi tệ hơn đối với bạn.
Gort Robot

5
Bạn đã đăng mã trực tuyến để nhận được một số hình thức trợ giúp. Tôi nhận ra rằng bạn không muốn / mong đợi tất cả các phản hồi về phong cách của bạn, nhưng bạn có muốn giúp đỡ gì không? Bạn lấy cái tốt với cái xấu. Các lập trình viên phải tìm kiếm các lỗi trong mã; đó là những gì chúng ta làm
JeffO

Câu trả lời:


26

Không thấy mã trong câu hỏi, có một số cách để viết mã Java trong C ++, một số cách tồi tệ hơn các cách khác.

  1. Ở một thái cực, đã đặt ra nguồn của bạn như Java: mọi thứ trong một tệp, mọi thứ trong định nghĩa lớp, v.v.:
    class HelloWorldApp {
    public:
        void main() {
            cout << "Hello World!" << endl;
        }
    };
    Đây là cách nguồn Java sẽ được trình bày. Về mặt kỹ thuật, nó hợp pháp trong C ++, nhưng đặt mọi thứ vào tệp tiêu đề và mọi thứ nội tuyến (bằng cách xác định nó trong khai báo lớp) là phong cách khủng khiếp và sẽ giết chết hiệu năng biên dịch của bạn. Đừng làm điều đó.
  2. Quá nhiều OO - Để đơn giản hóa, trong Java, đó là Vương quốc của Danh từ , nơi mọi thứ đều là một đối tượng. Mã C ++ tốt (nghĩa là thành ngữ) có nhiều khả năng sử dụng các hàm, mẫu miễn phí, v.v., thay vì cố gắng nhồi nhét mọi thứ vào một đối tượng.
  3. Không có RAII - Bạn đã đề cập đến điều này - sử dụng con trỏ và dọn dẹp thủ công thay vì con trỏ thông minh. C ++ cung cấp cho bạn các công cụ như RAII và con trỏ thông minh, do đó, mã C ++ tốt (nghĩa là thành ngữ) sử dụng các công cụ đó.
  4. Không có C ++ nâng cao - Các khái niệm cơ bản về Java và C ++ là tương tự nhau, nhưng một khi bạn có được các tính năng nâng cao hơn (các mẫu, thư viện thuật toán của C ++, v.v.), chúng bắt đầu phân kỳ.

Ngoại trừ # 1, không ai trong số này biến chương trình C ++ thành chương trình tồi, nhưng nó cũng không phải là loại mã tôi thích làm việc với tư cách là một lập trình viên C ++. (Tôi cũng sẽ không thích làm việc với Perl không thành ngữ hoặc kiểu C, Python không thành ngữ, v.v.) Một ngôn ngữ có các công cụ và thành ngữ và triết lý riêng, và mã tốt sử dụng các công cụ và thành ngữ đó thay vì cố gắng sử dụng mẫu số chung thấp nhất hoặc cố gắng tái tạo cách tiếp cận của ngôn ngữ khác. Viết mã không thành ngữ trong một ngôn ngữ / miền vấn đề cụ thể / bất cứ điều gì không làm cho ai đó trở thành một lập trình viên tồi, điều đó chỉ có nghĩa là họ có nhiều thứ để tìm hiểu về ngôn ngữ / miền vấn đề / bất cứ điều gì. Và không có gì sai với điều đó; có một danh sách rất dài những điều tôi có nhiều thứ để tìm hiểu và đặc biệt C ++ có rất nhiều thứ để học.

Liên quan đến câu hỏi cụ thể về việc viết mã dễ bị lỗi với mục đích làm sạch nó sau này, nó không phải là màu đen và trắng:

  • Nếu một số mã nguyên mẫu không thể xử lý mọi ngoại lệ có thể và mọi trường hợp góc có thể xảy ra, thì đó là điều được mong đợi. Làm cho nó hoạt động, sau đó làm cho nó hoạt động mạnh mẽ. Không vấn đề gì.
  • Nếu một số mã nguyên mẫu được viết theo kiểu đơn giản là xấu hoặc thiết kế xấu (xấu đối với ngôn ngữ đã cho và thành ngữ của nó, thì về cơ bản là thiết kế xấu cho vấn đề, v.v.), trừ khi bạn viết nó như một sự vứt bỏ bằng chứng về khái niệm, bạn không đạt được bất cứ điều gì.

Để sử dụng con trỏ nguyên so với con trỏ thông minh là một ví dụ, nếu bạn đang đi để làm việc trong C ++, sử dụng RAII và con trỏ thông minh là đủ cơ bản mà nó phải được nhanh hơn để viết mã theo cách đó hơn là quay trở lại và làm sạch nó lên sau đó. Một lần nữa, không làm điều này không có nghĩa là ai đó là một lập trình viên tồi, không chuyên nghiệp, v.v., nhưng nó có nghĩa là có nhiều thứ để học.


11
có thành ngữ perl?
ratchet freak

21
@Onno Khi bạn hỏi "Làm thế nào để tôi vặn ốc vít này vào tường mà không bị cong?" mọi người sẽ bảo bạn đừng dùng búa.
Sjoerd

9
@Onno Trong C ++, con trỏ và newđược coi là công cụ truyền động. Lưu trữ tự động là handtool.
Sjoerd

9
@Onno: Bạn phải nhận ra rằng các khóa học lập trình C ++ có xu hướng tụt hậu trong việc áp dụng các thành ngữ hiện đại và những gì được coi là C ++ tốt cũng đã phát triển rất nhiều kể từ khi C ++ được phát minh.
Bart van Ingen Schenau

7
Do lịch sử của C ++ và số lượng lớn các lập trình viên đã học ngôn ngữ này trước khi nhiều tính năng tiên tiến hơn của ngôn ngữ xuất hiện, có rất nhiều C ++ tào lao ngoài kia vẫn được viết bởi những người viết như họ đã làm cách đây một thập kỷ. Sự khó chịu về những thứ như RAII là về việc khiến mọi người sử dụng các phương pháp hiện đại để chúng ta có thể ngừng nhìn thấy những thất bại có thể dự đoán tương tự.
Gort Robot

42

Mỗi ngôn ngữ lập trình có một tập hợp các thành ngữ và thực tiễn tốt nhất, thường sẽ dẫn đến mã thanh lịch, chính xác và hiệu suất. Dưới đây là một vài thực tiễn tồi tệ nhất hoàn toàn tốt trong một số ngôn ngữ khác:

  • Tôi sẽ hét lên nếu bạn viết for ($i = 0; $i < 42; $i++) { … }bằng Perl, nhưng không phải bằng PHP
    (trong Perl, các biến nên được khai báo và các vòng lặp như vậy sẽ lặp lại trong một phạm vi)
  • Tôi sẽ khóc nếu bạn viết new Foo()bằng C ++ mà không có lý do chính đáng, nhưng không phải bằng Java
    (C ++ không có bộ sưu tập rác, vì vậy nên sử dụng RAII. Noobs sẽ rò rỉ bộ nhớ nếu không)
  • Tôi sẽ co rúm lại nếu bạn khai báo tất cả các biến của bạn ở đầu hàm, ngoại trừ trong C89, Pascal hoặc JavaScript.
  • Tôi sẽ facepalm nếu bạn đặt tất cả các hàm của mình vào một lớp trong Python, nhưng không phải bằng Java
    (Python là ngôn ngữ đa mô hình thay vì buộc OOP OOP và hỗ trợ các hàm ở cấp cao nhất)
  • Tôi sẽ khóc nếu bạn return nullở Scala, nhưng không phải ngôn ngữ giống C
    (vì Scala có một Optionloại)
  • Tôi sẽ phàn nàn nếu bạn viết một thuật toán đệ quy bằng Java, nhưng không phải bằng OCaml
    (vì ngăn xếp của Java tràn ra nhanh chóng, trong khi OCaml có tối ưu hóa cuộc gọi đuôi)
  • Giáo dục

Thật dễ dàng để sử dụng một ngôn ngữ mới như thể đó là thứ bạn biết, và với may mắn, nó thậm chí sẽ hoạt động. Bạn có thể viết Fortran bằng bất kỳ ngôn ngữ nào. Nhưng bạn thực sự không muốn bỏ qua các tính năng cụ thể mà ngôn ngữ X cung cấp, vì rất có thể X cung cấp một số lợi thế so với U.

Tôi chọn ngôn ngữ để sử dụng trong các điều khoản của thư viện có sẵn của nó và môi trường thực hiện tối ưu cho công việc trong tầm tay ” - nhưng dù ngôn ngữ này X là thực sự tốt hơn so với ngôn ngữ U cho công việc trong tầm tay cũng phụ thuộc vào cách làm quen với ngôn ngữ đó, hoặc Sẽ mất bao lâu để làm quen đủ để sử dụng nó tốt. Bạn sẽ không mang lại một cái cưa nặng chỉ vì nó chặt gỗ nhanh nhất, khi bạn thực sự muốn con dao bút cũ của mình vì nó vừa vặn với bàn tay của bạn. Trừ khi bạn thực sự muốn ngã một cái cây.

Nhưng câu hỏi của bạn là nhiều hơn về một vấn đề văn hóa : học tất cả các thực hành tốt nhất mất rất nhiều thời gian và người mới hỏi nhiều câu hỏi nhất, trong khi các bậc thầy trả lời chúng. Nhưng những gì rõ ràng đối với một đạo sư không rõ ràng đối với một người mới và đôi khi các bậc thầy đã quên điều đó. Là một người mới, giải pháp là không ngừng đặt câu hỏi. Tuy nhiên, người ta có thể thể hiện sự cởi mở để tìm hiểu và áp dụng các thực tiễn tốt nhất, ví dụ: bằng cách cố gắng làm sạch mã của bạn càng nhiều càng tốt trước khi hiển thị nó cho người khác. Hầu hết các ngôn ngữ đều có một vài thực hành tốt nhất cốt lõi dễ học, ngay cả khi toàn bộ quá trình học thực sự rất dài.

Một vấn đề phổ biến là những người mới lập trình không quan tâm đến bất kỳ sự thụt lề hoặc định dạng nào khác, và sau đó bị nhầm lẫn vì chương trình của họ không hoạt động. Tôi cũng sẽ bối rối, và bước đầu tiên để hiểu một chương trình là đảm bảo nó được bố trí hoàn hảo. Sau đó, các lỗi đơn giản như một trích dẫn đóng bị quên hoặc dấu phẩy bị mất đột nhiên trở nên rõ ràng. Tôi tin rằng bạn đã thực hành định dạng tốt và đây là một phép ẩn dụ cho các thực tiễn tốt nhất khác: thực tiễn tốt nhất ngăn ngừa lỗi, thực tiễn tốt nhất giúp tìm lỗi dễ dàng hơn, áp dụng các thực tiễn tốt nhất trước khi tìm ra vấn đề .

Thật quá rẻ khi nói rằng tôi sẽ sửa nó sau này, khi sửa nó bây giờ sẽ giải quyết được vấn đề của bạn lần đầu tiên). Ít nhất, cố gắng làm cho mã của bạn tốt nhất có thể trước khi nhờ người khác giúp đỡ giúp họ dễ dàng suy luận về mã của bạn hơn, đó là điều lịch sự cần làm.


Bạn hoàn toàn đúng về một số điểm bạn đưa ra, nhưng cuối cùng tôi không nghĩ bạn đang đạt điểm cao. Bạn đang giả định đạt được kiến ​​thức trước khi có kinh nghiệm sẽ thu được kiến ​​thức.
Onno

4
@Onno Điểm chính của tôi (trả lời các câu hỏi bạn đã hỏi) là bạn không thể thực hiện thói quen từ một ngôn ngữ và cho rằng đó là cách tốt nhất trong ngôn ngữ khác và cố gắng viết mã sạch ngay từ đầu là tốt hơn để làm sạch nó lên sau Làm sạch mã - với khả năng tốt nhất của bạn - là điều bắt buộc trước khi nhờ người khác giúp đỡ (xem sscce.org để biết các mẹo về đoạn mã tốt). Việc vứt mã rác trên SO bằng một bản sửa lỗi, vui lòng sửa lỗi này là không thể chấp nhận được, đặc biệt nếu bạn biết rõ hơn.
amon

2
Nhưng liên quan đến câu hỏi mà bạn đang gợi ý: câu trả lời của jm666 có một điểm mấu chốt: guru nghĩ rằng tại sao bạn lại hỏi về X nếu bạn không muốn tự mình trở thành một X-guru? . Một cách có thể để xoa dịu đó là đề cập đến việc bạn vẫn đang ở giai đoạn đầu của quá trình học tập và sẽ xem xét vấn đề đó sau, nhưng bây giờ có sẵn câu hỏi này ngay lập tức hơn. Tuy nhiên, đó là một vấn đề giao tiếp, không phải là một vấn đề lập trình.
amon

6
Cả C ++ và C # đều có optional<T>Nullable<T>tương ứng. Ngoài ra, thực tế tất cả mọi người đều rò rỉ bộ nhớ trong C ++ mà không có RAII, noob hay không.
DeadMG

Tôi thấy rằng việc khai báo các biến ở đầu một khối thường làm cho mã của bạn dễ đọc hơn trong hầu hết các ngôn ngữ. Bằng cách này, bạn biết chính xác nơi cần tìm khi bạn cần trợ giúp ghi nhớ loại tất cả các biến của bạn là gì và như vậy.
Thưởng thức

12

Tôi không phải là nhà phát triển C ++ khó tính, nhưng ...

Tại sao nó sẽ là một thực tiễn lập trình tồi khi sử dụng mã dễ bị lỗi hơn trong các tình huống nguyên mẫu, nếu việc tái cấu trúc làm cho nó mạnh hơn sau đó?

Một điều cần lưu ý là một lỗi trong C ++ thường có nghĩa là "hành vi không xác định". Trong một ngôn ngữ an toàn, điều tồi tệ nhất có thể xảy ra là một ngoại lệ chấm dứt chương trình của bạn ngay lập tức. Trong C ++, bạn may mắn nếu bạn nhận được một segfault. Hoàn toàn có thể chương trình của bạn tiếp tục làm điều gì đó sai một cách tinh vi. Nó cũng có thể hành xử chính xác trong một khoảng thời gian và xuất hiện nhiều lỗi sau đó, hoặc nó có thể hành xử chính xác mọi lúc nhưng cuối cùng lại ăn hết bộ nhớ của bạn.

Trong mọi trường hợp, chỉ cần một sai lầm duy nhất là thực hiện chương trình hoàn toàn khỏi đường ray và vào lãnh thổ chưa được khám phá. Có vẻ như đối với nhà phát triển C ++ toàn thời gian, "trường hợp cơ sở" có nghĩa là "không có khả năng hành vi không xác định hoặc rò rỉ bộ nhớ."

Làm thế nào để chương trình được viết bằng C ++ giống như được viết bằng Java? Điều gì làm cho nó một chương trình xấu?

Tôi không nghĩ rằng có một câu trả lời cho điều này sẽ không chủ yếu là suy đoán và ý kiến. Nếu bạn muốn tôi đảm nhận điều đó, Java có xu hướng có một vài phản mẫu được liên kết giống như thực tế là mọi thứ phải là một đối tượng. Trong trường hợp bằng các ngôn ngữ khác mà bạn muốn vượt qua một con trỏ, functor, hoặc chức năng, trong Java bạn thường tìm thấy tấn ngớ ngẩn và suýt-hữu ích ThingDoers, FooFactoriesIFrobnicatorsđó chỉ là chức năng trong ngụy trang.

Tương tự, trong các ngôn ngữ khác, bạn có thể chuyển một cấu trúc đơn giản hoặc cấu trúc không tên, trong Java để kết hợp chỉ 2 đối tượng vào một thùng chứa dữ liệu đơn giản yêu cầu bạn xác định trước một lớp NamedThing 30+ với setters, getters và Javadocs. Thiếu tính năng tương đối của Java buộc các lập trình viên phải thực hiện các backflips đôi hướng đối tượng để hoàn thành công việc đôi khi. Mã kết quả hiếm khi là thành ngữ bên ngoài Java.

Sau đó, có một thực tế là trong C ++, bạn cần một biểu đồ đối tượng rất đơn giản để quản lý bộ nhớ theo cách thủ công; thường là một đối tượng được sở hữu bởi chính xác một đối tượng khác. Trong Java, bạn không cần phải tuân theo các ràng buộc chặt chẽ như vậy, bởi vì trình thu gom rác đảm bảo mọi thứ sẽ được dọn sạch khi không còn tham chiếu đến chúng nữa. Vì vậy, chắc chắn có nguy cơ quản lý bộ nhớ không chính xác nếu bạn chỉ chuyển mã từ Java sang C ++.

Cuối cùng, nó chỉ có thể là tinh hoa. Tôi sẽ không giả vờ rằng họ chiếm đa số, nhưng tôi chắc chắn đã thấy một tình cảm "Tôi không cần một ngôn ngữ sẽ nắm tay tôi và ngăn tôi làm những điều ngu ngốc" giữa một số nhà phát triển C ++. Trong suy nghĩ của họ, C ++ là một ngôn ngữ "thực" và nếu bạn không thể xử lý các đặc điểm riêng thì bạn không phải là "lập trình viên thực sự".


1
Phần lớn này được giảm bớt với Java 8 - Lambdas cưỡi trong để chủ yếu là tiết kiệm trong ngày :-)
Martijn Verburg

@MartijnVerburg Đồng ý, bước tiến lớn đó. Nhưng vấn đề công nghệ là những người dễ dàng để sửa chữa! Thói quen cũ chết cứng và kỳ thị còn khó hơn. Heck, một số người sẽ đi xa đến mức phàn nàn Java không cần bất kỳ tính năng "mới" nào trong số này và đó là trên đường trở thành C ++ tiếp theo.
Doval

Vâng, tôi luôn lắc đầu về điều đó - Java sẽ cố tình luôn phát triển chậm hơn các ngôn ngữ khác vì đó là một công việc lâu dài. Tuy nhiên, JVM có thể nhảy về phía trước những bước nhảy vọt nhanh hơn một chút, đó là điều cho phép những thứ như Lambdas cuối cùng đến với ngôn ngữ.
Martijn Verburg

6

Hơi lạc đề trả lời ...

Đừng lo lắng - đây là một "hành vi" phổ biến trong bất kỳ cộng đồng chuyên gia nào. Và thành thật mà nói, nếu bạn giỏi bất kỳ ngôn ngữ nào, và bạn sẽ gặp một mã "lạ", có lẽ bạn cũng sẽ chỉ trích nó. (vì, muốn GIÁO DỤC).

Tôi đang ở trong thế giới perl - khi nào sẽ thấy một cái gì đó như:

$imax=$#array;
$str=""
for($i=0; $i<$imax; $i++) {
    $str = "$str" . $array[$i];
}

thay vì:

my $str = join '', @array;

chắc chắn sẽ bình luận nó - (đọc: dạy cho tác giả) về joinchức năng.

Dù sao, quá nhiều lời chỉ trích là phản tác dụng, và một trong những ví dụ tốt nhất là tiếp theo: (lấy từ: http://perl-begin.org/humour/#How_can_I_switch_off_the_T.V..3F )

(Bit này đã được đăng nặc danh lên một pastebot vào ngày 23 tháng 3 năm 2011. Nó được đặt ở đây cho hậu thế sau khi chỉnh sửa.) - chỉnh sửa một chút

Câu hỏi: làm thế nào tôi có thể bật TV của tôi?

OP muốn nghe gì?

Ví dụ: Xác định vị trí nút bật / tắt TV của bạn từ xa nhấn nó. Nút thường có màu đỏ và nằm ở dòng trên cùng trên điều khiển từ xa.

Câu trả lời của chuyên gia #perl: Đầu tiên, bạn có ý nghĩa gì với "bật"? Xác định nó trước. Nopaste TV, điều khiển TV và phòng khách cũng vậy.

... sau khi nopaste:

Căn phòng của bạn thật xấu xí. Và TV trông thật tệ. Sử dụng Mr. Clean trên màn hình và làm sạch phòng khách của bạn trước. Sử dụng ba cây lau nhà thay vì hai. Sử dụng HDMI và không bao giờ sử dụng đầu nối scart (?), Trừ khi bạn thực sự muốn. Điều khiển TV của bạn có các nút không thể đọc được, hãy dọn sạch trước. Bạn là người mới bắt đầu, vì vậy hãy đọc:

http://experts.blog/how_to_design_a_future_3D_TV.html http://experts.blog/the_basics_of_tv nb Pairing.html http://experts.blog/viruses_in_living_room_short_essay.html http://exper

Khách mời của IRC: Nhưng, tôi không muốn trở thành một chuyên gia truyền hình.

Trả lời: Tại sao bạn muốn bật TV sau đó?!


1
Câu trả lời này không lạc đề. Nó giải thích chính xác lý do tại sao một người nào đó sẽ chỉ trích việc sử dụng ngôn ngữ độc đáo và tại sao đôi khi sự chỉ trích tự động có thể đi quá xa. Tôi thích nó.
trichoplax

1

Tại sao nó sẽ là một thực tiễn lập trình tồi khi sử dụng mã dễ bị lỗi hơn trong các tình huống nguyên mẫu, nếu việc tái cấu trúc làm cho nó mạnh hơn sau đó?

Khi viết nhanh và bẩn với tâm trí sửa chữa sau này có nguy cơ quên một cái gì đó mà bạn cần sửa.

Làm thế nào để chương trình được viết bằng C ++ giống như được viết bằng Java? Điều gì làm cho nó trở thành một chương trình tồi, (xem xét rằng tôi đã chỉ ra ý định của phong cách hiện tại và công việc được lên kế hoạch để cải thiện?)

Trong java bạn không cần phải suy nghĩ về việc ai sở hữu một đối tượng nào đó, bạn chỉ cần chuyển tham chiếu cùng và quên nó đi như thể nó chẳng là gì cả. Tuy nhiên, trong C ++ cần có một định nghĩa rõ ràng về người sở hữu đối tượng và ai chịu trách nhiệm làm sạch nó.

Làm thế nào tôi trở thành một chuyên gia tồi nếu tôi chọn sử dụng một cấu trúc được sử dụng trong một mô hình lập trình nhất định (ví dụ: OOP / DP)

Bạn sẽ không; C ++ là một ngôn ngữ đa mô hình, nó tình cờ hỗ trợ OOP khá tốt nhưng nó cũng có thể làm rất nhiều thứ khác. Tuy nhiên, hầu hết đều tập trung vào việc sử dụng công cụ chính xác cho công việc thay vì rút búa mỗi khi bạn cần lái một mũi nhọn vào một số gỗ.

Lý do bạn nhận được phản hồi xấu là vì hầu hết mọi người trên SO có xu hướng đánh giá các kỹ năng bằng cách bạn có thể viết mã bằng ngôn ngữ mà bạn đang hỏi. Những người quen thuộc với C ++ có xu hướng giật đầu gối khi họ nhìn thấy mã xấu trông giống như thứ gì đó đã cắn họ trong quá khứ.


Tôi có thể thấy rằng việc quên cải thiện có thể là một vấn đề đối với một số người, nhưng tôi giữ một danh sách dài các nhiệm vụ và tôi rất kỷ luật trong việc thêm thẻ việc cần làm cho các loại công việc này. (đó là lý do tại sao tôi thích VS, nó khá tốt trong quản lý công việc) Nó cũng tương tự đối với tài liệu này. Tôi không viết một dòng mã trước khi tôi viết tài liệu cho nó. Đối với câu hỏi về quyền sở hữu, vì các sơ đồ trình tự, tôi nghĩ rằng tôi có một ý tưởng tốt về ai có liên kết với ai.
Onno

1
@Onno: Thành thật mà nói, không ai biết hoặc quan tâm cá nhân bạn tốt như thế nào trong việc theo dõi những thứ đó. Đại đa số những người viết C ++ trông giống Java hoặc C, thậm chí không quá tỉ mỉ. Lần đầu tiên họ học cách làm công cụ tốt hơn là tự viết một ghi chú để quay lại và sửa nó sau, bởi vì kinh nghiệm cho thấy thực tế họ không bao giờ thực sự làm điều đó.
cHao
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.