Tại sao trong hầu hết các ngôn ngữ lập trình hiện đại (Go, Rust, Kotlin, Swift, Scala, Nim, thậm chí Python phiên bản cuối cùng) luôn xuất hiện sau tên biến trong khai báo biến chứ không phải trước?

Tại sao x: int = 42và không int x = 42?
Là cái sau không dễ đọc hơn cái trước?
Nó chỉ là một xu hướng hoặc có bất kỳ lý do thực sự có ý nghĩa đằng sau giải pháp này?

Tất cả các ngôn ngữ bạn đề cập đến suy luận loại hỗ trợ , có nghĩa là loại đó là một phần tùy chọn của khai báo trong các ngôn ngữ đó vì chúng đủ thông minh để tự điền nó khi bạn cung cấp một biểu thức khởi tạo có loại dễ xác định.

Điều đó quan trọng bởi vì đặt các phần tùy chọn của biểu thức xa hơn bên phải sẽ giảm phân tích sự mơ hồ và tăng tính nhất quán giữa các biểu thức sử dụng phần đó và phần không biểu thức. Việc phân tích một khai báo chỉ đơn giản hơn khi bạn biết vartừ khóa và tên biến là bắt buộc trước khi bạn có được các công cụ tùy chọn. Về lý thuyết, tất cả những điều giúp phân tích cú pháp cho máy tính dễ dàng hơn cũng sẽ cải thiện khả năng đọc tổng thể cho con người, nhưng điều đó còn gây tranh cãi hơn nhiều.

Lập luận này được đặc biệt mạnh mẽ khi bạn xem xét tất cả các tùy chọn bổ kiểu đó một ngôn ngữ "không hiện đại" như C ++ có, chẳng hạn như *đối với con trỏ, &tài liệu tham khảo, const, volatilevà vân vân. Khi bạn ném vào dấu phẩy cho nhiều khai báo, bạn bắt đầu nhận được một số sự mơ hồ thực sự kỳ lạ như int* a, b;không tạo ra bmột con trỏ.

Ngay cả C ++ hiện cũng hỗ trợ khai báo "gõ bên phải" ở dạng auto x = int{ 4 };và nó có một số lợi thế .

Tại sao trong gần như tất cả các ngôn ngữ lập trình hiện đại (Go, Rust, Kotlin, Swift, Scala, Nim, thậm chí phiên bản Python cuối cùng) luôn xuất hiện sau khai báo biến, chứ không phải trước?

Tiền đề của bạn là thiếu sót trên hai mặt trận:

• Có những ngôn ngữ lập trình mới có loại trước định danh. C, D, hoặc Ceylon chẳng hạn.
• Có loại sau khi định danh không phải là một hiện tượng mới, nó quay trở lại ít nhất là Pascal (được thiết kế năm 196819191969, phát hành năm 1970), nhưng thực sự đã được sử dụng trong lý thuyết loại toán học, bắt đầu ~ 1902. Nó cũng được sử dụng trong ML (1973), CLU (1974), Hope (1970), Modula-2 (1977 Hóa1985), Ada (1980), Miranda (1985), Caml (1985), Eiffel (1985), Oberon (1986), Modula-3 (1986 Từ1988) và Haskell (1989).

Pascal, ML, CLU, Modula-2 và Miranda đều là những ngôn ngữ có ảnh hưởng rất lớn, vì vậy không có gì đáng ngạc nhiên khi phong cách khai báo kiểu này vẫn phổ biến.

Tại sao x: int = 42và không int x = 42? Là cái sau không dễ đọc hơn cái trước?

Khả năng đọc là một vấn đề quen thuộc. Cá nhân, tôi thấy tiếng Trung là không thể đọc được, nhưng rõ ràng, người Trung Quốc thì không. Học Pascal ở trường, học hỏi về Eiffel, F♯, Haskell và Scala, và đã xem TypeScript, Fortress, Go, Rust, Kotlin, Idris, Frege, Agda, ML, Ocaml, Nott, nó trông hoàn toàn tự nhiên đối với tôi .

Nó chỉ là một xu hướng hoặc có bất kỳ lý do thực sự có ý nghĩa đằng sau một giải pháp như vậy?

Nếu đó là một xu hướng, nó khá dai dẳng: như tôi đã đề cập, nó đã tồn tại hàng trăm năm trong toán học.

Một trong những lợi thế chính của việc có loại sau mã định danh, là dễ dàng loại bỏ loại này nếu bạn muốn nó được suy ra. Nếu khai báo của bạn trông như thế này:

val i: Int = 10

Sau đó, thật là tầm thường khi loại bỏ các loại và suy ra nó như thế này:

val i = 10

Trong khi đó nếu loại đi trước định danh như thế này:

Int i = 10

Sau đó, nó bắt đầu khó phân tích cú pháp để phân biệt một biểu thức với một khai báo:

i = 10

Giải pháp mà các nhà thiết kế ngôn ngữ thường đưa ra là giới thiệu từ khóa "Tôi không muốn viết một loại" phải viết thay vì loại:

var  i = 10; // C♯
auto i = 10; // C++

Nhưng điều này thực sự không có nhiều ý nghĩa: về cơ bản bạn phải viết một loại rõ ràng rằng bạn không viết một loại. Huh? Sẽ dễ dàng và hợp lý hơn nhiều nếu chỉ bỏ nó đi, nhưng điều đó làm cho ngữ pháp phức tạp hơn nhiều.

(Và chúng ta thậm chí không nói về các loại con trỏ hàm trong C.)

Các nhà thiết kế của một số ngôn ngữ nói trên đã cân nhắc về chủ đề này:

• Câu hỏi thường gặp (xem thêm: Cú pháp khai báo của Go ):

  Tại sao khai báo ngược?

  Chúng chỉ ngược nếu bạn đã quen với C. Trong C, khái niệm là một biến được khai báo giống như một biểu thức biểu thị loại của nó, đó là một ý tưởng hay, nhưng ngữ pháp loại và biểu thức không trộn lẫn rất tốt và kết quả có thể gây nhầm lẫn; xem xét con trỏ hàm. Đi phần lớn tách biệt cú pháp biểu thức và kiểu và đơn giản hóa mọi thứ (sử dụng tiền tố *cho con trỏ là một ngoại lệ chứng minh quy tắc). Trong C, khai báo

  int* a, b;
  

  tuyên bố alà một con trỏ nhưng không b; trong đi

  var a, b *int
  

  tuyên bố cả hai là con trỏ Điều này là rõ ràng và thường xuyên hơn. Ngoài ra, :=biểu mẫu khai báo ngắn lập luận rằng một khai báo biến đầy đủ sẽ trình bày cùng thứ tự như :=vậy

  var a uint64 = 1
  

  có tác dụng tương tự như

  a := uint64(1)
  

  Phân tích cú pháp cũng được đơn giản hóa bằng cách có một ngữ pháp riêng biệt cho các loại không chỉ là ngữ pháp biểu thức; từ khóa như funcvà changiữ cho mọi thứ rõ ràng.

• Câu hỏi thường gặp về Kotlin :

  Tại sao có khai báo kiểu bên phải?

  Chúng tôi tin rằng nó làm cho mã dễ đọc hơn. Bên cạnh đó, nó cho phép một số tính năng cú pháp tốt đẹp. Ví dụ, thật dễ dàng để bỏ các chú thích loại. Scala cũng đã chứng minh khá tốt đây không phải là vấn đề.

• Lập trình trong Scala :

  Độ lệch lớn so với Java liên quan đến cú pháp cho các chú thích kiểu Đây là " variable: Type" thay vì " Type variable" trong Java. Cú pháp loại hậu tố của Scala giống với Pascal, Modula-2 hoặc Eiffel. Lý do chính cho sự sai lệch này liên quan đến suy luận kiểu, điều này thường cho phép bạn bỏ qua loại biến hoặc kiểu trả về của phương thức. Sử dụng variable: Typecú pháp "", điều này thật dễ dàng, chỉ cần bỏ dấu hai chấm và kiểu. Nhưng trong Type variablecú pháp " " kiểu C ", bạn không thể bỏ qua kiểu kiểu Haiti, sẽ không có điểm đánh dấu để bắt đầu định nghĩa nữa. Bạn cần một số từ khóa thay thế để trở thành một trình giữ chỗ cho một loại bị thiếu (C♯ 3.0, một số loại suy luận, sử dụng varcho mục đích này). Một từ khóa thay thế như vậy cảm thấy đặc biệt hơn và ít thường xuyên hơn so với cách tiếp cận của Scala.

Lưu ý: các nhà thiết kế của Ceylon cũng ghi lại lý do tại sao họ sử dụng cú pháp loại tiền tố :

Tiền tố thay vì chú thích loại hậu tố

Tại sao bạn theo dõi C và Java trong việc đặt các chú thích kiểu trước, thay vì Pascal và ML đặt chúng sau tên khai báo?

Bởi vì chúng tôi nghĩ rằng:

shared Float e = ....
shared Float log(Float b, Float x) { ... }

Đơn giản là dễ đọc hơn nhiều so với điều này:

shared value e: Float = .... 
shared function log(b: Float, x: Float): Float { ... }

Và chúng tôi chỉ đơn giản là không hiểu làm thế nào bất cứ ai có thể nghĩ khác!

Cá nhân, tôi thấy "lập luận" của họ kém thuyết phục hơn những người khác.

Nhân tiện, Pascal cũng làm điều đó và không phải là một ngôn ngữ mới. Đó là một ngôn ngữ hàn lâm, được thiết kế từ đầu.

Tôi muốn nói rằng nó rõ ràng hơn về mặt ngữ nghĩa để bắt đầu với tên biến. Loại chỉ là một chi tiết kỹ thuật. Nếu bạn muốn đọc lớp của bạn giống như mô hình của thực tế, thì nên đặt tên của các thực thể của bạn trước và triển khai kỹ thuật của chúng sau cùng.

C # và java xuất phát từ C nên họ phải tôn trọng "nghệ thuật trước", để không nhầm lẫn với lập trình viên có kinh nghiệm.

Tại sao x: int = 42và không int x = 42? Là cái sau không dễ đọc hơn cái trước?

Trong một ví dụ đơn giản như vậy, không có nhiều khác biệt, nhưng hãy làm cho nó phức tạp hơn một chút: int* a, b;

Đây là một tuyên bố hợp lệ thực tế trong C, nhưng nó không làm những gì nó trực quan trông giống như nó nên làm. Có vẻ như chúng ta đang khai báo hai biến loại int*, nhưng thực ra chúng ta đang khai báo một int*và một biến int.

Nếu ngôn ngữ của bạn đặt loại sau tên biến (s) trong khai báo của nó, vấn đề đó là không thể chạy vào.