Một ngôn ngữ lập trình bằng cách thiết kế có thể thực thi mã sạch sạch không? [đóng cửa]

Vì vậy, tôi đang mã hóa các dự án đầu tiên của mình trong C ++ và có vẻ như phải mất nhiều công sức hơn để làm cho mã "sạch", thay vì chỉ hoạt động. Tức là có vẻ như C ++ "cho phép" viết mã xấu, nhưng làm việc.

Điều đó làm tôi suy nghĩ,

Một ngôn ngữ lập trình có thể thực thi mã sạch theo thiết kế không? Có những ngôn ngữ như vậy đã?

Ngoài ra, làm thế nào điều này được kết hợp làm nguyên tắc thiết kế trong phát triển / lý thuyết ngôn ngữ lập trình? Những loại biện pháp được sử dụng?

Hiệu ứng chính mà thiết kế ngôn ngữ có trên "mã sạch" là ở cấp độ cú pháp. Các ngôn ngữ có nhiều toán tử tốc ký và toán tử tối nghĩa (Perl / APL) cho vay mã "bẩn", trong khi các ngôn ngữ có tập hợp các phần tử nhỏ hơn (giả sử, Python) cho vay mã sạch hơn.

Ngữ nghĩa, tuy nhiên, là một động vật rất khác nhau. Không có cách nào để thực thi rằng ngữ nghĩa của ngôn ngữ được sử dụng một cách sạch sẽ, đặc biệt bởi vì bạn không thể, với tư cách là trình biên dịch, biết người dùng ngôn ngữ đang cố gắng đạt được điều gì. Một công cụ mạnh mẽ chỉ đơn giản là - một công cụ mạnh mẽ, tốt hay xấu.

Vào cuối ngày, ngữ nghĩa quan trọng hơn cú pháp. Đây cũng là phần khó nhất để trở thành một nhà phát triển bảo trì (ví dụ: "mã này thực sự có nghĩa là gì? Tôi thấy nó làm gì ...").

Do đó, tôi sẽ nói rằng không có thiết kế để thực thi mã sạch, nhưng bạn có thể viết cú pháp đơn giản với ngữ nghĩa sạch sẽ giúp dễ dàng hơn. Dù tốt hay xấu, mã sạch chủ yếu là vấn đề về kiến ​​thức, động lực, kỷ luật và kỹ năng của nhà phát triển.

Các ngôn ngữ có thể buộc hoặc khuyến khích các lập trình viên giải quyết các lớp lỗi nhất định, là một phần của định nghĩa về mã sạch. Ví dụ, các ngôn ngữ khác nhau thực hiện công việc tương đối tốt:

• Ngoại lệ con trỏ Null.
• Chia sẻ lỗi nhà nước.
• Vấn đề đồng thời.
• Ngoại lệ không được kiểm tra.

Điều đó chỉ giúp bạn trở thành một phần của cách đó, bởi vì mã sạch chủ yếu là về giao tiếp giữa người với người . Ngôn ngữ lập trình thực sự chỉ có một đòn bẩy để hỗ trợ việc này và đó là sức mạnh biểu cảm của chúng . Đó là một thuật ngữ thực sự khó định nghĩa, nhưng về cơ bản, các lập trình viên giỏi sẽ dễ dàng viết mã sạch hơn bằng các ngôn ngữ biểu cảm hơn. Họ có nhiều công cụ hơn để dễ dàng diễn đạt một thuật toán theo cách giao tiếp tốt với người khác. Đừng hiểu sai ý tôi, bạn có thể viết mã sạch bằng ( gần như ) bất kỳ ngôn ngữ lập trình nào. Đó chỉ là một số ngôn ngữ làm cho nó dễ dàng hơn và có kết quả tương đối tốt hơn.

Tuy nhiên, bạn không thể quay số biểu cảm và mọi người sẽ bắt đầu viết mã tốt hơn. Với hầu hết các lập trình viên, bạn cung cấp cho họ nhiều nút hơn để chuyển sang ngôn ngữ của họ và họ sẽ không biết cách sử dụng chúng đúng cách, vì vậy mã của họ thực sự tồi tệ hơn. Cần có kỷ luật và sự hướng dẫn tốt để cải thiện chất lượng mã của bạn. Không có đạn bạc.

Đến một mức độ nào. Nhiều ngôn ngữ được thiết kế có chủ ý để khuyến khích một số dạng mã sạch theo lý tưởng của các nhà thiết kế ngôn ngữ. Chắc chắn có thể viết mã xấu xí và không thể hiểu được bằng bất kỳ ngôn ngữ nào, nhưng một số ngôn ngữ làm nhiều nỗ lực hơn để ngăn cản nó.

Như một ví dụ Python buộc bạn phải thụt các khối theo cấu trúc ngữ nghĩa của ngôn ngữ, trong khi nhiều ngôn ngữ khác cho phép bạn thụt lề hoàn toàn ngẫu nhiên hoặc hoàn toàn không. Đây là một ví dụ về một ngôn ngữ tích cực khuyến khích một lý tưởng sạch sẽ nhất định.

Nếu bạn có thể định lượng nó, bạn có thể tạo một ngôn ngữ có thể tối ưu hóa nó.

Mặc dù tôi không biết bất kỳ ngôn ngữ cụ thể nào thực sự áp dụng chính sách "mã sạch", các cảnh sát kiểu chạy trên bản dựng là khá phổ biến.

Lý do chính mà đây là một bước riêng biệt để được đưa vào ngôn ngữ phần lớn là một chức năng của các ưu tiên. Đó là lợi ích tốt nhất của ngôn ngữ lập trình để cho phép các nhà lập trình linh hoạt nhất để có được mức độ áp dụng rộng nhất. Có rất nhiều ngôn ngữ lập trình và DSL khác nhau hạn chế cơ sở người dùng một cách giả tạo bằng cách kén chọn và quan điểm về những gì đầu vào được phép có thể sẽ có được theo cách áp dụng rộng rãi hơn.

Ví dụ: đó không phải là lợi ích tốt nhất của C # để buộc mọi người viết

if (condition)
{

thay vì

if (condition) {

Nhưng những người kiểm tra phong cách có thể bị coi là một người kén chọn vì đó là những gì họ được thiết kế để làm.

Vì vậy, để trả lời câu hỏi

Một ngôn ngữ lập trình có thể thực thi mã sạch theo thiết kế không?

_{nhấn mạnh của tôi}

Hoàn toàn, miễn là bạn cung cấp một định nghĩa mạnh mẽ cho "mã sạch" nghĩa là gì.

Ví dụ: tôi có thể định nghĩa "mã sạch" có nghĩa là:

• độ dài dòng không quá 80 ký tự
• các chức năng bao gồm không quá 100 dòng
• thụt phải là hai không gian
• dấu ngoặc nhọn mở phải theo sau ở cuối dòng trước chính xác một khoảng trắng
• không quá hai toán tử trên mỗi dòng

và bạn có thể không đồng ý với một số hoặc tất cả các quy ước này, nhưng vào cuối ngày, chúng có thể định lượng được và có thể được thi hành theo chương trình.

Không, không phải theo nghĩa mà bạn mô tả. Phát hiện "sự xấu xí" không thể được thực hiện tự động!

Tuy nhiên, các nhà thiết kế ngôn ngữ có thể làm những điều để khuyến khích mã tốt (tôi không muốn nói "sạch" vì đôi khi mã tốt, an toàn cũng dài và "xấu"). Ví dụ, các nhà thiết kế ngôn ngữ Rust đã xem xét những điều mà các lập trình viên C ++ có kỷ luật có xu hướng làm (như đưa ra các giá trị phân bổ heap cho một "chủ sở hữu") và làm cho việc thực hiện một số điều đó dễ dàng hơn. Điều này bao gồm việc cung cấp một máy đánh chữ mà bạn có thể sử dụng để kiểm tra xem bạn đã không mắc phải một số lỗi phổ biến nhất định.

Tôi muốn nói rằng thiết kế ngôn ngữ tốt thường phản ứng: các nhà thiết kế nhìn vào những gì lập trình viên giỏi làm và cố gắng làm cho điều đó dễ dàng hơn và "đẹp hơn".