Blog cộng đồng về Công nghệ thông tin

--- oOo ---

Chắc chắn điều này sẽ gây rất nhiều phiền phức cho tôi, nhưng tôi xin thú nhận công khai rằng tôi thuộc phe ma giáo, như cách hiểu trong truyện chưởng. (Ở đây tôi chỉ thú nhận là phản đạo trong ngữ cảnh của ngành thiết kế ngôn ngữ máy tính. Những thú nhận phản đạo khác xin chờ dịp khác.)

Xin nói ngay rằng: Đối với hầu như bất kì ngôn ngữ phổ biến nào (C, Java, C++, Python, Lisp, Ada, FORTRAN, Smalltalk, sh, JavaScript, v.v.) vấn đề coding style về căn bản đã được giải quyết, và chúng ta không cần lo lắng gì nữa. Và để bây giờ không cần lo lắng gì nữa, thì đáng lẽ cần cân nhắc kĩ về coding style ngay từ lúc khởi đầu, và cách tốt nhất là ép mọi người phải dùng một coding style duy nhất như là một phần của cú pháp.

Đấy. Tôi nói thế đấy. Tôi muốn nói rằng, ví dụ, chuẩn ANSI C mới nên định nghĩa coding style kiểu K&R vào trong ngôn ngữ luôn. Chương trình dùng chuần mới này buộc phải viết theo kiểu K&R, nếu không trình biên dịch sẽ không thèm dịch và báo lỗi cú pháp.

Tôi xin dừng trong chốc lát để các bạn suy nghĩ. Bởi vì khi tôi trình bày điều này trên mailing list, tôi đã phải giải thích đi giải thích lại nhiều lần. Nhiều người không hiểu, vì họ không thể tin có người lại thốt ra điều này. Ý của tôi đúng là như vậy đấy. Ví dụ cụ thể, tôi muốn ngữ pháp mới của phiên bản C mới định nghĩa khoảng trắng giữa từ khóa và dấu mở ngoặc: if (foo) là hợp lệ, còn if(foo) thì không. Khi biên dịch, trình biên dịch sẽ không báo warning, mà không thèm dịch luôn.

Dưới đây là lí do:

• Tiền đề 1. Bất kì ngôn ngữ nào, cũng có vài coding style phổ biến.
  Điển hình là một sytle được tác giả ngôn ngữ đưa ra, các style khác phát triển theo thời gian. Ví dụ như C.
• Tiền đề 2. Chưa từng, và sẽ không bao giờ có style nào tốt hơn những style khác.
  Thực tế cho thấy, việc tìm ra style gì đó giúp tăng năng suất lập trình lên vài phần trăm rất giống như việc tìm ra tư thế làm tình mới. (Không áp dụng cho phi hành gia)
• Tiền đề 3. Có hàng nghìn thứ phiền phức gây ra bởi việc có nhiều style.
  Nghĩ thử xem: Có bao nhiêu project có mục đích tạo reformatter trên SourceForge? Có bao nhiêu tranh luận về chủ đề này?
• Tiền đề 4. Với đa số project, việc thống nhất dùng một coding style là điều rất tốt.
  Tôi nghĩ đa số đều đồng ý. Project có vài người tham gia, mỗi người dùng một style khác nhau, thì thật là củ chuối. Những project tôi biết đều chỉ dùng một style, thậm chí đôi khi khách hàng yêu cầu phải dùng style của họ.
• Kết luận: Khi coi tất cả code trên thế giới đều cùng thuộc một "project" với chỉ một style, chúng ta được nhiều lợi ích hơn là dùng nhiều style.

--0o0---

Nghỉ xem nào. Gom tất Web pages, sổ nhật kí, nhật báo, emails sử dụng chung cùng một style. Định dạng lại các tham số của các style là cách tốt nhất,do đó reformat trở thành một công cụ mang ý nghĩa.

Và hầu hết: là ko có tranh chấp giữa các style. Thực vậy sao? hãy nghỉ về tất cả những chu kì này, khi đó chúng ta có thể cày(plow) vào trong nhiều quá trình sản xuất, giống như là vi/emacs.

Lẽ dĩ nhiên, bạn sẽ ko bao giờ ép buộc bất cứ style nào trừ khi người ta ko có sự lựa chọn nào khác. Nhiều lập trình viên C sử dụng 1 văn phong đối với từ khóa "while". Hoặc là bỏ qua các dấu ngoặc đơn bao quanh mệnh đề "if", họ sẽ ko làm như vậy, vì họ ko thể thực hiện đc. Nhưng họ có thể sửa lại chúng.

Vì thế tôi muốn có một ngôn ngữ chuẩn để làm đc điều này. Tôi muốn phiên bản kế của những ngôn ngữ này để yêu cầu bất kì một đoạn mã, sử dụng những tính năng mới để thích nghi với 1 vài kiểu.  Chúng ta biết C sẽ đi với kiểu "K&R", C++ sẽ đi với kiểu "Bjarne", còn java thì đi với kiểu của Sun như đc chỉ ra trên "language spec" và những quyển sách về java, kiểu "Lisp" thì hầu như đã sẵn sàng thiết lập trong "stone".

Hầu hết những nguyên tắc về style đều phải làm việc với sự sắp đặt của các khoảng trắng: một dòng mới đc thêm vào trc, hoặc sau những ngoặc móc, khoảng trắng bao quanh các toán tử, hoặc là ko vv.... Vì thế tôi sẽ nói rằng ngôn ngữ đó chú ý về khoảng trắng rất nhiều.

Chưa có một điều gì mà chúng tôi cho rằng đã học từ các ngôn ngữ giống như FORTRAN, mà khoảng trắng đc cho là có ý nghĩa, đánh dấu vòng quanh giữa các thẻ bài. Điều này đc chấp nhận bởi vì FORTRAN có các cột - cột đầu trong 5 cột sẽ phục vụ cho số câu lệnh hoặc là 1 chỉ báo comment, cột thứ 6 với bất kì một kí tự nào sẽ tiếp tục ở dòng trc, cột 7 tới 72 sẽ có code, và cột thứ 8 sẽ phục vụ cho các con số hữu dụng cho việc sắp xếp lại trật tự. Vì thế nếu bạn thêm cái gì đó vào trong cột sai, 1 câu lệnh trở thành 1 commnent hoặc bất cứ 1 cái gì khác, mà gây ra phiền phức. Vì thế, DO10I=1, thì 100 sẽ bằng với DO 10 I = 1, 100 là vì DO là 1 keywork theo sau bởi 1 con số, và khoảng trắng ko đc yêu cầu, thông qua đó gán DO10I=1, như là gán 1 vào biến có tên là DO10I.

Nguồn: The Best Software Writing I

Gốc: Style Is Substance