Một điều cần lưu ý là mã được đọc thường xuyên, đến các "độ sâu" khác nhau. Mã này:
PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();
rất dễ "lướt qua". Đó là 3 tuyên bố. Đầu tiên chúng ta đến với a PowerManager
. Sau đó, chúng tôi đến với a WakeLock
. Sau đó chúng tôi acquire
các wakeLock
. Tôi có thể thấy điều đó thực sự dễ dàng chỉ bằng cách nhìn vào điểm bắt đầu của mỗi dòng; các bài tập biến đơn giản thực sự dễ dàng nhận ra một phần là "Gõ varName = ..." và chỉ lướt qua "...". Tương tự, câu lệnh cuối cùng rõ ràng không phải là hình thức của bài tập, nhưng nó chỉ liên quan đến hai tên, vì vậy "ý chính" là rõ ràng ngay lập tức. Thường thì đó là tất cả những gì tôi cần biết nếu tôi chỉ cố gắng trả lời "mã này làm gì?" ở mức độ cao
Nếu tôi đang theo đuổi một lỗi tinh vi mà tôi nghĩ là ở đây, thì rõ ràng tôi sẽ cần phải xem xét vấn đề này chi tiết hơn nhiều, và thực sự sẽ nhớ "..." s. Nhưng cấu trúc câu lệnh riêng biệt vẫn giúp tôi thực hiện một câu lệnh đó tại một thời điểm (đặc biệt hữu ích nếu tôi cần đi sâu hơn vào việc thực hiện những điều được gọi trong mỗi câu lệnh; khi tôi quay lại tôi đã hiểu đầy đủ "một đơn vị" và sau đó có thể chuyển sang tuyên bố tiếp theo).
((PowerManager)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
.acquire();
Bây giờ tất cả chỉ là một tuyên bố. Cấu trúc cấp cao nhất không dễ đọc lướt qua; trong phiên bản gốc của OP, không có ngắt dòng và thụt lề để giao tiếp trực quan với bất kỳ cấu trúc nào, tôi sẽ phải đếm các dấu ngoặc đơn để giải mã nó thành một chuỗi gồm 3 bước. Nếu một số biểu thức đa phần được lồng vào nhau thay vì được sắp xếp như một chuỗi các lệnh gọi phương thức, thì nó vẫn có thể trông giống như thế này, vì vậy tôi phải cẩn thận khi tin vào điều đó mà không tính dấu ngoặc đơn. Và nếu tôi tin tưởng vào vết lõm và chỉ lướt qua điều cuối cùng là điểm được cho là của tất cả những điều này, thì điều gì sẽ .acquire()
nói với tôi về chính nó?
Đôi khi, mặc dù, đó có thể là những gì bạn muốn. Nếu tôi áp dụng nửa chuyển đổi của bạn và viết:
WakeLock wakeLock =
((PowerManeger)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();
Bây giờ điều này giao tiếp với một skim nhanh "có được WakeLock
, sau đó acquire
nó". Thậm chí đơn giản hơn phiên bản đầu tiên. Rõ ràng ngay lập tức rằng thứ được mua là a WakeLock
. Nếu việc lấy PowerManager
chỉ là một chi tiết phụ không đáng kể so với điểm của mã này, nhưng điều wakeLock
quan trọng là, thì nó thực sự có thể giúp chôn vùi những PowerManager
thứ đó để lướt qua nó nếu bạn chỉ cố gắng nhanh chóng lướt qua nó. ý tưởng về những gì mã này làm. Và không đặt tên nó truyền đạt rằng nó là chỉ sử dụng một lần, và đôi khi đó là Điều quan trọng (nếu phần còn lại của phạm vi rất dài, tôi phải đọc tất cả những điều đó để biết liệu nó có được sử dụng lại hay không, mặc dù sử dụng phạm vi phụ rõ ràng có thể là một cách khác để giải quyết vấn đề đó, nếu ngôn ngữ của bạn hỗ trợ chúng).
Điều này dẫn đến tất cả phụ thuộc vào bối cảnh và những gì bạn muốn giao tiếp. Cũng như viết văn xuôi bằng ngôn ngữ tự nhiên, luôn có nhiều cách để viết một đoạn mã nhất định về cơ bản tương đương về mặt nội dung thông tin. Cũng như viết văn xuôi bằng ngôn ngữ tự nhiên, cách bạn chọn giữa chúng thường không nên áp dụng các quy tắc cơ học như "loại bỏ bất kỳ biến cục bộ nào chỉ xảy ra một lần". Thay vì như thế nàobạn chọn viết ra mã của bạn sẽ nhấn mạnh những điều nhất định và không nhấn mạnh những điều khác. Bạn nên cố gắng thực hiện những lựa chọn đó một cách có ý thức (bao gồm cả lựa chọn viết mã ít đọc hơn vì lý do kỹ thuật đôi khi), dựa trên những gì bạn thực sự muốn nhấn mạnh. Đặc biệt hãy suy nghĩ về những gì sẽ phục vụ những độc giả chỉ cần "lấy ý chính" của mã của bạn (ở nhiều cấp độ khác nhau), vì điều đó sẽ xảy ra thường xuyên hơn nhiều so với cách đọc biểu thức rất gần.