Chương 8: (Trang 31-43)

Bước 4: Viết và kiểm tra mã của Đối tượng hành động

• Chuyển đổi logic được thể hiện trong mã giả sang ngôn ngữ lập trình (sử dụng bộ
từ vựng và cú pháp của một ngôn ngữ).
• Kiểm tra và sửa mã đối tượng được viết, giai đoạn này được gọi là gỡ lỗi.

Bước 5: Kiểm tra dự án tổng thể

• Kiểm tra toàn bộ project cần đảm bảo mỗi câu lệnh phải hoàn toàn chính xác nếu
không thì chương trình có thể sẽ có lỗi.
• Cần đảm bảo chương trình được kiểm tra trên môi trường và dữ liệu thực thi thực
tế mà chương trình sẽ được sử dụng.

Bước 6: Viết tài liệu cho dự án

• Tài liệu bao gồm các mô tả bằng hình ảnh và văn bản của phần mềm trong đó
chứa các mô tả phần lập trình và các mô tả hoặc hướng dẫn bên ngoài.
• Tài liệu là cần thiết vì dù sớm hay muộn, chương trình sẽ cần được bảo trì (sửa
lỗi, thêm tính năng mới, xử lý các vấn đề chưa từng nghĩ tới, v.v.) Điều này
KHÔNG thể thực hiện được nếu không có tài liệu.
• Tài liệu có thể bao gồm sách, hướng dẫn sử dụng và các mục tiêu của phần mềm.
5. Quy ước viết mã
Hướng dẫn viết mã:
• Nguyên tắc viết mã cung cấp cho lập trình viên một tập hợp các phương pháp .
• Làm cho các chương trình đễ đọc và bảo trì.
Các lưu ý cần thiết khi viết mã:

1. Độ dài dòng: Việc giữ nguyên độ dài dòng được coi là một cách thực hành tốt
độ dài của dòng mã nguồn bằng hoặc dưới 80 ký tự. Dòng lâu hơn thời gian này có
thể không hiển thị chính xác trên một số thiết bị đầu cuối và công cụ. Một số máy
in sẽ cắt bớt dòng dài hơn hơn 80 cột.
2. Khoảng cách: Việc sử dụng khoảng trắng thích hợp trong một dòng mã có thể
cải thiện khả năng đọc.
3. Mã phải được ghi chép đầy đủ: Theo nguyên tắc chung, trung bình phải có ít
nhất một dòng bình luận cho mỗi dòng ba nguồn.
4. Độ dài của bất kỳ hàm nào cũng không được vượt quá 10 nguồn dòng: Một hàm
rất dài thường rất khó để hiểu vì nó có thể thực hiện nhiều chức năng khác nhau.
Vì lý do tương tự, các hàm dài có thể có một số lượng lỗi lớn hơn một cách không
tương xứng.
5. Không sử dụng câu lệnh goto: Việc sử dụng câu lệnh goto khiến một chương
trình không có cấu trúc và rất khó hiểu.
6. Nhận xét nội tuyến: Nhận xét nội tuyến thúc đẩy khả năng đọc.
7. Thông báo lỗi: Xử lý lỗi là một khía cạnh thiết yếu của lập trình máy tính. Điều
này không chỉ bao gồm việc thêm logic cần thiết để kiểm tra và xử lý lỗi nhưng
cũng liên quan đến làm cho thông báo lỗi có ý nghĩa.

Phong cách lập trình

• Các kỹ thuật được sử dụng để viết mã nguồn cho một chương trình. Hầu hết các
phong cách lập trình được thiết kế để giúp lập trình viên nhanh chóng đọc và hiểu
chương trình cũng như tránh mắc lỗi.
• Một phong cách viết mã tốt có thể khắc phục nhiều khiếm khuyết của ngôn ngữ
lập trình.
• Mục tiêu của phong cách lập trình tốt là cung cấp mã đơn giản và dễ hiểu.
• Phong cách lập trình được sử dụng trong một chương trình khác nhau có thể bắt
nguồn từ các tiêu chuẩn mã hóa hoặc quy ước mã của một công ty hoặc tổ chức
máy tính khác, cũng như sở thích của lập trình viên thực tế.
Các lưu ý phong cách lập trình:

1. Cách diễn đạt rõ ràng và đơn giản: Chương trình phải được thiết kế sao cho đạt
được mục tiêu của chương trình thông thoáng.
2. Đặt tên: Trong một chương trình, bạn phải đặt tên cho module, các quy trình và
biến ...
3. Cấu trúc điều khiển: Điều mong muốn là càng nhiều càng tốt cấu trúc một lối
vào và lối ra duy nhất được sử dụng.
4. Ẩn thông tin: Thông tin được bảo mật trong dữ liệu cấu trúc nên được ẩn khỏi
phần còn lại của hệ thống nơi khả thi. Việc che giấu thông tin có thể làm giảm sự
liên kết giữa module và làm cho hệ thống dễ bảo trì hơn.
5. Lồng nhau: Việc lồng sâu các vòng lặp và điều kiện gây tổn hại lớn đến trạng
thái tĩnh và hành vi năng động của một chương trình. Nó cũng trở nên khó khăn để
hiểu logic chương trình, vì vậy nên tránh lồng sâu.
6. Kiểu do người dùng xác định: Tận dụng nhiều kiểu dữ liệu do người dùng xác
định như enum, lớp, cấu trúc và liên minh. Những kiểu dữ liệu này làm cho
chương trình của bạn mã dễ viết và dễ hiểu.
7. Kích thước mô-đun: Kích thước mô-đun phải đồng nhất. Kích thước của mô-đun
không được quá lớn hoặc quá nhỏ. Nếu kích thước mô-đun quá lớn, nó thường
không gắn kết về mặt chức năng. Nếu kích thước mô-đun quá nhỏ, nó
dẫn tới những chi phí không cần thiết.
8. Giao diện mô-đun: Một mô-đun có giao diện phức tạp phải được được kiểm tra
cẩn thận.
9. Tác dụng phụ: Khi một mô-đun được gọi, đôi khi nó có tác dụng phụ sửa đổi
trạng thái của chương trình. Tác dụng phụ như vậy nên tránh khi càng tốt.