Programming Style (2)

Các idiom

Không biết dịch từ “idiom” thế nào cho chính xác. Tạm hiểu idiom là các chuẩn không bắt buộc nhưng được đa số người dùng tuân theo. Sử dụng các idiom giúp giảm bớt khả năng mắc lỗi đồng thời làm chương trình dễ đọc hơn và nhất là có vẻ “chuyên nghiệp” hơn Sau đây là một số idiom phổ biến:

Các idiom cho mảng

Để duyệt qua n phần tử của một mảng và khởi tạo chúng, có các cách viết sau đây:

i = 0;
while ( i <= n – 1 )
    array[ i++ ] = 1.0;

hoặc

for( i = 0; i < n; )
    array[ i++ ] =  1.0;

hoặc

for( i = n; –i >= 0; )
    array[ i ] = 1.0;

Tất cả những cách viết trên đều đúng, tuy nhiên idioms cho trường hợp này là:

for( i = 0; i < n; i++ )
    array[ i ] = 1.0;

Idiom của vòng lặp duyệt qua các phần tử của một danh sách (list) là

for( p = list; p != NULL; p = p->next )
    ...

Đối với các vòng lặp vô hạn, idiom là

for ( ; ; )
...

hoặc

while( 1 )
    ...

Các idiom cho xâu và kí tự

Xem đoạn mã sau đây:

Programming Style (1)

Sau một thời gian ra trường và đi làm với công việc chính là lập trình, nhiều khi tôi nhìn lại thời đại học và giật mình vì thấy mình đã học lập trình một cách quá hời hợt. Có rất nhiều kiến thức cơ bản mà tôi đã không học (hay không được dạy?). Nhớ lại hồi năm thứ nhất học Pascal, chúng tôi được học các lệnh if the, while, for…với các ví dụ kiểu như tìm tất cả các ước số của một số nguyên, hay quản lí sắp xếp sinh viên…Đến năm thứ 3 học C, chúng tôi vẫn học từng ý lệnh với từng ý kiểu bài tập. Có quá nhiều những kiến thức vô cùng quan trọng mà các thầy không hề nhắc đến (chứ chưa nói gì đến dạy), chẳng hạn như: Phong cách lập trình (Programming Style), kĩ thuật gỡ lỗi (debug), kiểm thử (test), hiệu năng của chương trình (performance), tính khả chuyển (portable)…Đáng tiếc là sự tồn tại của những kiến thức này lại không hiển nhiên cho lắm để sinh viên có thể tự tìm sách để đọc.

Một trong những cuốn sách tuyệt vời viết về những chủ đề nói trên là cuốn “The practice of Programming” của Brian W. Kernighan và Rob Pike (tôi ước là mình biết đến cuốn sách này sớm hơn). Đây là một cuốn sách được “recommend” cho tất cả các lập trình viên của tất cả các ngôn ngữ lập trình. Trong bài viết này tôi muốn giới thiệu chương đầu tiên của cuốn sách với tiêu đề “Style”. Những chương tiếp theo tôi sẽ giới thiệu khi có thời gian, hoặc tốt nhất là mọi người tự tìm đọc bản tiếng Anh để hấp thu được toàn bộ sự sâu sắc của cuốn sách. (Tôi có bản mềm của cuốn sách này, ai cần có thể PM)

Phong cách lập trình (programming style)

Mở đầu

Hãy xem đoạn mã sau đây:

if ( ( country == SING ) || ( country == BRNI ) ||
     ( country == POL ) || ( country == ITALY ) ) {
    /*
     * If the country is Singapore, Brunei or Poland
     * then the current time is the answer time
     * rather than the off hook time
     * Reset answer time and set day of week
     */
    ...
}

Đoạn mã trên được viết một cách rất đẹp đẽ, được comment cẩn thận và là một phần trong một chương trình chạy hoàn toàn đúng. Tuy nhiên đoạn mã này vẫn gây ra một chút băn khoăn cho người đọc: Những đất nước Singapore, Brunei, Poland và Italy có mối liên hệ gì với nhau? Tại sao Italy lại không được nói đến trong phần comment? Vì đoạn mã và phần comment có sự khác nhau nên một trong hai thứ phải sai mà cũng có thể là cả hai đều sai. Đoạn mã có nhiều khả năng đúng hơn vì nó đã được test; có thể phần comment đã không được cập nhật theo sự thay đổi của đoạn mã. Nếu là người bảo trì cho đoạn chương trình này, rất có thể bạn cần phải biết mối quan hệ giữa các quốc gia được nhắc đến.

Đoạn chương trình nói trên đại diện cho phần lớn các chương trình trong thực tế: Hầu hết chạy đúng nhưng vẫn cần phải cải tiến.

Mục đích của style là làm cho chương trình trở nên dễ đọc đối với người viết và những người khác, một style tốt là một phần thiết yếu của việc lập trình tốt. Viết một chương trình chạy đúng là chưa đủ bởi chương trình không chỉ để cho máy tính đọc mà còn để các lập trình viên khác đọc. Hơn nữa, một chương trình có style tốt luôn có nhiều khả năng chạy đúng hơn một chương trình có style tồi.

Vậy thế nào là một style tốt? Điều đó tùy thuộc vào quy định của từng công ty, tổ chức, dự án…Phần sau đây giới thiệu những style cơ bản nhất.