Tôi không bao giờ hiểu những tuyên bố như thế này. Thành thật mà nói, ngay cả khi bạn khai báo kiểu trả về của hàm, bạn có thể và sẽ quên nó sau khi bạn đã viết nhiều dòng mã và bạn vẫn sẽ phải quay lại dòng mà nó đã khai báo bằng hàm tìm kiếm của trình soạn thảo văn bản của bạn để kiểm tra nó.
Không phải là bạn quên kiểu trả về - điều này luôn xảy ra. Đó là về công cụ có thể cho bạn biết rằng bạn đã quên loại trả về.
Ngoài ra, vì các hàm được khai báo bằng loại funcname()..., loại biết trắng mà bạn sẽ phải tìm kiếm trên mỗi dòng trong đó hàm được gọi, bởi vì bạn chỉ biết funcname, trong khi trong Python và giống như bạn chỉ có thể tìm kiếm def funcnamehoặc function funcnamechỉ xảy ra một lần , tại tờ khai.
Đây là một vấn đề của cú pháp, hoàn toàn không liên quan đến gõ tĩnh.
Cú pháp họ C thực sự không thân thiện khi bạn muốn tra cứu một tờ khai mà không có các công cụ chuyên dụng theo ý của bạn. Các ngôn ngữ khác không có vấn đề này. Xem cú pháp khai báo của Rust:
fn funcname(a: i32) -> i32
Hơn nữa, với REPL, việc kiểm tra một hàm cho kiểu trả về của nó với các đầu vào khác nhau là rất đơn giản, trong khi với các ngôn ngữ được nhập tĩnh, bạn sẽ cần thêm một số dòng mã và biên dịch lại mọi thứ chỉ để biết loại được khai báo.
Bất kỳ ngôn ngữ nào cũng có thể được diễn giải và bất kỳ ngôn ngữ nào cũng có thể có REPL.
Vì vậy, ngoài việc biết kiểu trả về của một hàm rõ ràng không phải là điểm mạnh của các ngôn ngữ được nhập tĩnh, cách gõ tĩnh thực sự hữu ích trong các dự án lớn hơn?
Tôi sẽ trả lời một cách trừu tượng.
Một chương trình bao gồm nhiều hoạt động khác nhau và các hoạt động đó được đặt ra theo cách chúng là do một số giả định mà nhà phát triển đưa ra.
Một số giả định là ngầm định và một số là rõ ràng. Một số giả định liên quan đến một hoạt động gần họ, một số liên quan đến một hoạt động cách xa họ. Một giả định sẽ dễ dàng hơn để xác định khi nó được thể hiện rõ ràng và càng gần càng tốt với những nơi mà giá trị thật của nó quan trọng.
Một lỗi là biểu hiện của một giả định tồn tại trong chương trình nhưng không giữ trong một số trường hợp. Để theo dõi một lỗi, chúng ta cần xác định giả định sai lầm. Để loại bỏ lỗi, chúng ta cần xóa giả định đó khỏi chương trình hoặc thay đổi một cái gì đó để giả định thực sự giữ.
Tôi muốn phân loại các giả định thành hai loại.
Loại đầu tiên là các giả định có thể có hoặc không giữ, tùy thuộc vào đầu vào của chương trình. Để xác định một giả định sai lầm của loại này, chúng ta cần tìm kiếm trong không gian của tất cả các đầu vào có thể có của chương trình. Sử dụng những phỏng đoán có giáo dục và suy nghĩ hợp lý, chúng ta có thể thu hẹp vấn đề và tìm kiếm trong một không gian nhỏ hơn nhiều. Tuy nhiên, khi một chương trình phát triển dù chỉ một chút, không gian đầu vào ban đầu của nó tăng với tốc độ rất lớn - đến mức có thể coi là vô hạn cho tất cả các mục đích thực tế.
Loại thứ hai là các giả định chắc chắn giữ cho tất cả các đầu vào, hoặc chắc chắn là sai cho tất cả các đầu vào. Khi chúng tôi xác định một giả định loại này là sai, chúng tôi thậm chí không cần chạy chương trình hoặc kiểm tra bất kỳ đầu vào nào. Khi chúng tôi xác định một giả định loại này là chính xác, chúng tôi có một nghi ngờ ít quan tâm hơn khi chúng tôi theo dõi một lỗi ( bất kỳ lỗi nào ). Do đó, có giá trị trong việc có càng nhiều giả định càng tốt thuộc về loại này.
Để đặt một giả định trong danh mục thứ hai (luôn luôn đúng hoặc luôn luôn sai, không phụ thuộc vào đầu vào), chúng ta cần một lượng thông tin tối thiểu có sẵn tại nơi giả định được đưa ra. Trên toàn bộ mã nguồn của chương trình, thông tin sẽ bị cũ khá nhanh (ví dụ: nhiều trình biên dịch không thực hiện phân tích liên văn bản, điều này khiến cho bất kỳ cuộc gọi nào trở thành ranh giới cứng đối với hầu hết thông tin). Chúng tôi cần một cách để giữ cho thông tin được yêu cầu mới (hợp lệ và gần đó).
Một cách là để nguồn thông tin này càng gần càng tốt với nơi nó sẽ được tiêu thụ, nhưng điều đó có thể không thực tế đối với hầu hết các trường hợp sử dụng. Một cách khác là lặp lại thông tin thường xuyên, làm mới mức độ liên quan của nó qua mã nguồn.
Như bạn đã có thể đoán, các loại tĩnh chính xác là như vậy - đèn hiệu của thông tin loại nằm rải rác trong mã nguồn. Thông tin đó có thể được sử dụng để đặt hầu hết các giả định về tính chính xác của loại trong loại thứ hai, có nghĩa là hầu như mọi hoạt động đều có thể được phân loại là luôn luôn đúng hoặc luôn không chính xác về khả năng tương thích loại.
Khi các loại của chúng tôi không chính xác, phân tích giúp chúng tôi tiết kiệm thời gian bằng cách đưa lỗi đến sự chú ý của chúng tôi sớm hơn là muộn. Khi các loại của chúng tôi là chính xác, phân tích giúp chúng tôi tiết kiệm thời gian bằng cách đảm bảo rằng khi xảy ra lỗi, chúng tôi có thể loại trừ ngay các lỗi loại.