13: Các vấn đề về cấu trúc code

Rất lâu trước đây, tôi đã làm việc trên một hệ thống Cobol nơi nhân viên không được phép thay đổi thụt đầu dòng trừ khi họ có lý do để thay đổi code, bởi vì ai đó đã từng phá vỡ một vài thứ bằng cách để một dòng trượt vào một trong những cột đặc biệt ở đầu dòng. Điều này bị áp dụng ngay khi bố cục sai lệch, đôi khi nó là như vậy, vì vậy chúng tôi phải đọc code rất cẩn thận vì chúng tôi không thể tin tưởng được. Các chính sách phải có chi phí rất lớn trong việc lôi kéo lập trình viên.

Có nghiên cứu cho rằng tất cả chúng ta dành nhiều thời gian lập trình để điều hướng và đọc code - tìm nơi để thực hiện thay đổi - hơn là thực sự gõ, vì vậy đây là điều chúng tôi muốn tối ưu hóa.

• Dễ nhìn. Mọi người rất giỏi trong việc kết hợp các mô hình trực quan( một phần còn sót lại từ hồi chúng ta phải nhận ra con sư tử trên thảo nguyên). Vì vậy tôi có thể tự giúp bản thân mình bằng cách làm cho mọi thứ không được liên quan trực tiếp đến đường dẫn, làm cho tất cả "sự phức tạp ngẫu nhiên" đi kèm với hầu hết các ngôn ngữ thương mại, mờ dần đi bằng cách chuẩn hóa nó. Nếu code hoạt động giống nhau mà nhìn giống nhau, thì hệ thống nhận thức của tôi sẽ giúp tôi chọn ra sự khác biệt. Đó là lý do tại sao tôi cũng quan sát các quy ước về cách bố trí các phần của một lớp trong một đơn vị biên dịch: hằng, trường, phương thức public, phương thức private.
• Bố cục có hàm ý. Tất cả chúng ta đã học cách dành thời gian để đặt tên để code của chúng ta thể hiện rõ ràng nhất có thể những gì nó làm, thay vì chỉ liệt kê các bước - phải không? Bố cục của code cũng là một phần của tính có hàm ý này. Việc cắt giảm đầu tiên là để nhóm đồng ý về một trình định dạng tự động cho những điều cơ bản, sau đó tôi có thể điều chỉnh bằng tay trong khi tôi đang viết code. Trừ khi có sự bất đồng chính kiến, một nhóm sẽ nhanh chóng hội tụ theo kiểu "hoàn thành thủ công" chung. Một định dạng không thể hiểu được ý định của tôi (tôi nên biết, tôi đã từng viết một lần) và điều quan trọng hơn với tôi là việc ngắt dòng và nhóm các phản ánh mục đích của code lại, không chỉ là cú pháp của ngôn ngữ. (Kevin McGuire đã giải thoát cho tôi khỏi sự trói buộc với các trình định dạng code tự động.)
• Quy ước định dạng. Càng nhìn vào màn hình nhiều, tôi càng có thể nhận thấy mà không phá vỡ ngữ cảnh bằng cách cuộn hoặc chuyển đổi tập tin, điều đó có nghĩa là tôi có thể giữ trạng thái ít hơn trong đầu. Nhận xét thủ tục dài và nhiều khoảng trắng có ý nghĩa đối với tên 8 ký tự và in dòng, nhưng bây giờ tôi sống trong một IDE có tô màu cú pháp và liên kết chéo. Điểm ảnh là yếu tố giới hạn của tôi vì vậy tôi muốn mọi người đóng góp theo hướng hiểu biết của tôi về code. Tôi muốn bố trí để giúp tôi hiểu code, nhưng không nhiều hơn thế.

Một người bạn không phải lập trình viên đã từng nhận xét rằng code trông giống như thơ vậy. Tôi có được cảm giác đó từ code thực sự tốt, rằng mọi thứ trong văn bản đều có mục đích và nó ở đó để giúp tôi hiểu ý tưởng. Thật không may, viết code không có hình ảnh lãng mạn giống như viết thơ.