Có phải mục đích đằng sau mã là 'thành ngữ' để giảm chi phí nhận thức?

Tôi đang cố gắng giải thích với ai đó rằng cách họ viết mã khiến bạn khó hiểu và nếu bạn cấu trúc lại nó thì sẽ dễ đọc hơn. Kiểu mã này tôi đang lái xe thường được gọi là 'mã' thành ngữ '.

Nhưng cụm từ mã thành ngữ mang theo hành lý đúng đắn về mặt đạo đức , đây không phải là động lực tuyệt vời để khiến mọi người thay đổi phong cách mã hóa. Một cách tích cực hơn để nói đây là mã theo phong cách chung - nhưng đối với một nhà tư tưởng phê phán đi qua như lý luận tâm lý bầy đàn.

Cách tôi nghĩ ra để giải thích ý tưởng này theo cách thúc đẩy mọi người thay đổi mã của họ là:

• viết mã theo cách nó làm giảm chi phí nhận thức của người đọc (ví dụ tôi không thể nhớ nếu đây là loại vectơ đầu tiên - hay loại vectơ thứ 5)
• mã giúp dễ hiểu mục đích hơn (ví dụ: vectơ này để làm gì?)

. ).

Câu hỏi của tôi là: Mục đích đằng sau mã là 'thành ngữ' để giảm chi phí nhận thức?

Đầu tiên, tôi không chắc chắn rằng có bất kỳ loại "tính đúng đắn đạo đức" nào trong thuật ngữ "thành ngữ". Các định nghĩa từ điển đơn giản chỉ đơn giản là

đặc thù hoặc đặc trưng của một ngôn ngữ hoặc phương ngữ cụ thể: thành ngữ tiếng Pháp.

Có, mã thành ngữ thường làm giảm chi phí nhận thức, đặc biệt là tại các định nghĩa giao diện trong đó các thư viện tiêu chuẩn và bất kỳ thư viện bên thứ ba nào mà dự án cần (hầu như) đều là thành ngữ.

Tuy nhiên, như một điểm bán hàng, tôi tập trung vào việc giảm chi phí nhận thức cho bạn. Nó giúp các lập trình viên dễ dàng phát hiện ra các lỗi hơn vì họ không cố gắng làm sáng tỏ mã được viết theo một kiểu duy nhất để tìm ra nơi mà nó được xử lý một cách tinh tế bởi một hoặc xử lý sai một trường hợp cạnh. Nó giúp việc xem xét mã của người khác dễ dàng hơn, điều đó có khả năng nhóm sẽ thực hiện các đánh giá thực tế xác định các vấn đề thực sự hơn là tranh luận về cú pháp.

Ngoài việc giảm chi phí nhận thức, mã thành ngữ thường là mã hiệu quả hơn. Hầu hết các thành ngữ trong một ngôn ngữ cụ thể phát triển vì ngôn ngữ được thiết kế để tiếp cận các vấn đề theo một cách cụ thể. Trình biên dịch hoặc trình thông dịch mà bạn đang sử dụng sẽ tập trung tối ưu hóa chúng vào mã thành ngữ. Ví dụ, nếu bạn sử dụng một ngôn ngữ trong đó đệ quy là cách thành ngữ để cấu trúc một đoạn mã, bạn có thể chắc chắn rằng trình biên dịch của bạn thực hiện đệ quy đuôi. Nếu bạn sử dụng một ngôn ngữ mà đệ quy là không thành ngữ, điều đó sẽ ít xảy ra hơn. Không chắc là đệ quy đuôi không thể được thực hiện ở mọi nơi nhưng hầu hết các tác giả biên dịch sẽ không tập trung vào những điều không xảy ra phổ biến.

Tôi không chắc bạn lấy ý tưởng từ đâu mà thành ngữ có bất kỳ ý nghĩa đạo đức nào. Thành ngữ chỉ là một cách để thể hiện sự vật. Chúng là các mẫu ở quy mô lớn hơn các từ hoặc cụm từ riêng lẻ.

Nếu tôi nói với bạn rằng người ta phải hú với bầy sói, bạn sẽ không biết ý tôi là gì, mặc dù đó là một thành ngữ nổi tiếng của Đức. Nếu, OTOH, tôi đã nói với bạn, khi ở Rome, làm như người La Mã làm, bạn sẽ biết ngay những gì tôi đang nói, bởi vì tôi đã sử dụng thành ngữ tiếng Anh thích hợp.

Ngôn ngữ máy tính cũng không khác.

Trên thực tế, một tên thay thế cho "thành ngữ" trong thế giới lập trình là "mẫu triển khai". Điều này liên quan đến ý tưởng cho ý tưởng về các mẫu, xuất phát từ kiến ​​trúc sư (gạch không phải bit và byte) Christopher Alexander. Hầu hết các lập trình viên đều biết về Mẫu thiết kế, một số người biết về Mẫu kiến ​​trúc, đó là các mẫu có tỷ lệ lớn hơn Mẫu thiết kế. Thành ngữ là các mẫu trên quy mô nhỏ hơn các mẫu thiết kế.

Hầu hết các ngôn ngữ cố ý cho vay theo một phong cách cụ thể. Mã được viết theo phong cách đó là những gì thành ngữ. Nếu bạn nhìn qua thực tế hoàn cảnh rằng bạn chọn môi trường thời gian chạy thu hẹp lựa chọn ngôn ngữ có sẵn của bạn, bạn nên chọn ngôn ngữ vì vấn đề trong tay rất dễ diễn đạt trong các thành ngữ cụ thể của ngôn ngữ.

Hầu hết mọi người không có được điều đó mặc dù. Ví dụ, nhiều lập trình viên Java cố gắng giữ phong cách giống nhau khi họ phải viết JavaScript (họ có thể đã viết Java và biên dịch chéo nó, nhớ bạn) và thành công ở một mức độ nào đó - viết mã là thành ngữ Java trong JavaScript - nhưng họ sẽ luôn có cảm giác chiến đấu với JavaScript. Thiếu một số tính năng nhất định hoặc thấy khó để mô phỏng chúng.

Mã thành ngữ là tốt. Đó là khó khăn cho người ngoài, nhưng họ có thể học hỏi. Cuối cùng, mã phải được duy trì trong nhiều năm, vì vậy nếu bạn có thể tìm thấy một ngôn ngữ trong các thành ngữ mà chương trình cơ bản có thể được diễn đạt theo cách đơn giản, đó là điều bạn nên làm.

Hãy để tôi làm rõ rằng chắc chắn có một thứ như lạm dụng các thành ngữ (hoặc các tính năng ngôn ngữ cơ bản). Nếu bạn sử dụng các mẫu C ++ để thực thi các phần quan trọng của logic ứng dụng vào thời gian biên dịch hoặc nếu chương trình Lisp hoàn chỉnh của bạn là một cuộc gọi đến một macro nào đó mở ra điều thực tế theo những cách thực tế không thể đoán trước, nếu giải pháp Java của bạn gặp vấn đề đơn giản tỷ lệ của FizzBuzz EntrypriseEdition ... bạn đang làm sai.

Mọi người nói mã phải dễ đọc. Đó chỉ là một nửa sự thật. Nó phải dễ hiểu, đòi hỏi nó phải dễ lý luận về điều đó. Điều đó đòi hỏi một sự sử dụng đầy đủ của trừu tượng. Như với hầu hết mọi thứ, đó là một vấn đề về sự cân bằng đúng đắn.