Phong cách cài đặt chương trình

Tài liệu chương trình được hiểu là tài liệu bên trong của chương trình gốc. Nó bắt đầu với việc chọn lựa các tên gọi định danh, tiếp đến là vị trí và thành phần của việc chú thích, và kết luận với cách tổ chức trực quan của chương trình.

Việc lựa chọn các tên gọi định danh có nghĩa chính là điều chủ chốt cho việc hiểu chương trình. Những ngôn ngữ giới hạn tên biến hay nhãn chỉ có trong vài ký tự nên tự nó đã mang nghĩa mơ hồ. Nhưng ý nghĩa thông thường phải được áp dụng khi tên gọi đã được chọn, các tên gọi dài không cần thiết đôi lúc có thể đưa ra tiềm năng lỗi. Các nghiên cứu đã chỉ ra rằng cho dù một chương trình nhỏ thì một tên gọi có nghĩa cũng làm tăng tính dễ hiểu. Theo ngôn từ của mô hình cú pháp/ngữ nghĩa, tên có ý nghĩa làm "đơn giản hoá việc chuyển đổi từ cú pháp chương trình sang cấu trúc ngữ nghĩa bên trong".

Khả năng diễn tả những lời chú thích theo ngôn ngữ tự nhiên như một phần của bản in chương trình gốc đều được mọi ngôn ngữ lập trình cung cấp. Tuy nhiên, một số vấn đề nảy sinh:

 Bao nhiêu chú thích là "đủ"?

 Nên đặt chú thích vào đâu?

 Chú thích có che mờ luồng logic không?

 Chú thích có làm lạc hướng độc giả không?

 Liệu có chú thích "không bảo trì" không, và do đó không tin cậy được?

Tuy vậy, một điều là rõ ràng: phần mềm phải chứa tài liệu bên trong. Lời chú thích cung cấp cho người phát triển một ý nghĩa truyền thông với các độc giả khác về chương trình gốc. Lời chú thích có thể cung cấp một hướng dẫn rõ rệt, dễ hiểu trong khâu bảo trì của công nghệ phần mềm.

Có nhiều hướng dẫn đã được đề nghị cho việc viết lời chú thích. Các chú thích mở đầu và chú thích chức năng là hai phạm trù đòi hỏi cách tiếp cận có hơi khác. Lời chú thích mở đầu nên xuất hiện ở ngay đầu của mọi module. Định dạng cho lời chú thích như thế là:

1. Một phát biểu về mục đích chỉ rõ chức năng module.

2. Mô tả giao diện bao gồm:

a) Mẫu lời gọi,

b) Mô tả về mọi đối số,

c) Danh sách tất cả các module thuộc cấp.

3. Thảo luận về dữ liệu thích hợp như các biến quan trọng và những hạn chế và giới hạn về cách dùng chúng, và các thông tin quan trọng khác.

4. Lịch sử phát triển bao gồm:

a) Tên người thiết kế module (tác giả),

b) Tên người xét duyệt (kiểm toán) và ngày tháng, c) Ngày tháng sửa đổi và mô tả sửa đổi,

Các chú thích mô tả được nhúng vào bên trong thân của chương trình gốc và được dùng để mô tả cho các hàm xử lý. Lời chú thích nên đưa ra một điều gì đó phụ trợ, không chỉ là lời diễn giải chương trình. Bên cạnh đó, lời chú thích mô tả nên:

 Mô tả các khối chương trình, thay vì chú thích cho từng dòng.

 Dùng dòng trống hay thụt cấp để cho lời chú thích có thể được phân biệt với chương trình

 Phải đúng đắn; một lời chú thích không đúng hay gây ra hiểu sai thì còn tồi tệ hơn là không có chú thích nào cả.

Với những tên gọi tượng trưng đúng đắn và việc chú thích tốt, việc làm tài liệu bên trong thích hợp sẽ được đảm bảo.

Khi một thiết kế thủ tục chi tiết được biểu diễn bằng cách dùng một ngôn ngữ thiết kế chương trình thì tài liệu thiết kế có thể được nhúng trực tiếp vào trong văn bản chương trình gốc như những câu chú thích. Kỹ thuật này đặc biệt có ích khi việc làm tài liệu được thực hiện trong hợp ngữ và giúp đảm bảo rằng cả chương trình và thiết kế sẽ được bảo trì khi những thay đổi được thực hiện cho cả hai.

Việc viết thụt cấp ở chương trình gốc chỉ ra kết cấu và khối logic của chương trình sao cho những thuộc tính này là thấy được so với lề bên trái. Giống như việc chú thích, cách tiếp cận tốt nhất tới việc thụt cấp là nên để mở cho tranh luận. Việc thụt cấp thủ công có thể trở nên phức tạp khi có sự sửa đổi chương trình và kinh nghiệm chỉ ra rằng khi đã tích luỹ đủ hiểu biết thì sẽ tăng cường được việc để lề cho khớp. Có lẽ cách tiếp cận tốt nhất là dùng bộ định dạng chương trình tự động (như công cụ CASE) sẽ đặt đúng việc thụt cấp cho chương trình gốc. Nó xoá bỏ đi gánh nặng của việc làm thụt cấp cho người lập trình, và có thể cải thiện khuôn dạng chương trình với tương đối ít nổ lực.

Độ phức tạp và việc tổ chức cấu trúc dữ liệu được xác định trong bước thiết kế nhưng phong cách khai báo dữ liệu thì được thiết lập khi chương trình được sinh ra. Thứ tự khai báo dữ liệu nên được chuẩn hoá cho dù ngôn ngữ lập trình không có yêu cầu bắt buộc. Điều này tạo điều kiện thuận lợi cho việc kiểm thử, gỡ rối và bảo trì. Thậm chí, khi có nhiều định danh được khai báo trong câu lệnh thì việc sắp xếp theo trật tự chữ cái cho các tên gọi đó cũng có giá trị.

Nếu thiết kế có mô tả trước cấu trúc dữ liệu phức tạp thì nên dùng chú thích để giải thích các điểm đặc thù trong cài đặt ở ngôn ngữ lập trình.

Mặc dầu việc xây dựng luồng logic phần mềm được thiết lập ở thiết kế nhưng việc xây dựng câu lệnh nằm ở bước lập trình. Thực tế đã chứng minh, việc xây dựng các câu lệnh của chương trình nên tuân theo phong cách lập trình cấu trúc. Các câu lệnh nên đơn giản và trực tiếp, không bị xoắn vào nhau để đảm bảo hiệu quả.

Trong thể hiện chương trình, cách xây dựng câu lệnh đơn và việc thụt cấp chương trình minh hoạ cho đặc trưng logic và chức năng của giai đoạn này, và nên tuân theo các chỉ dẫn:

+ Tránh dùng các phép kiểm tra điều kiện phức tạp,

+ Khử bỏ các phép kiểm tra điều kiện phủ định,

+ Tránh lồng nhau giữa các điều kiện hay chu trình,

+ Dùng các dấu ngoặc để làm sáng tỏ các biểu thức,

+ Dùng các dấu cách và các ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh,...

Phong cách vào/ra được thiết lập khi phân tích và thiết kế phần mềm nhưng cách thức cài đặt vào/ra lại ảnh hưởng lớn đến người sử dụng hệ thống. Phong cách vào/ra sẽ thay đổi theo mức độ tương tác con người.

Với vào/ra theo lô thì cách tổ chức cái vào logic, kiểm tra lỗi vào/ra có nghĩa, phục hồi lỗi vào/ra tốt và định dạng báo cáo ra hợp lý là những đặc trưng mong muốn. Với vào/ra tương tác thì một sơ đồ đưa vào có hướng dẫn, đơn giản, việc kiểm tra lỗi kỹ lưỡng và có thể phục hồi, sự nhất quán định dạng vào/ra lại là các mối quan tâm chủ yếu.

Khi cài đặt vào/ra, cần thoả mãn các tiêu chí cơ bản sau:

+ Làm hợp lệ mọi cái vào,

+ Kiểm tra sự tin cậy của các tổ hợp dữ liệu vào quan trọng,

+ Giữ cho định dạng dữ liệu vào đơn giản,

+ Dùng các chỉ báo cuối dữ liệu thay vì yêu cầu người sử dụng xác định số các khoản mục vào,

+ Đặt nhãn cho các dữ liệu vào,

+ Giữ các định dạng dữ liệu vào thống nhất,...