Đăng ký
Cộng đồng phát triển game Việt - kết nối đam mê !

 


Mình học lập trình từ năm lớp 8, bắt đầu với ngôn ngữ Pascal. Sau đó, mình đã tìm hiểu Delphi, Visual Basic, ASP, C/C++, Java, PHP, Javascript, Assembly, C#, Ruby, Python, ... khá nhiều ngôn ngữ, học được nhiều thứ và đa số có thể sử dụng và đã sử dụng trong dự án thật (mình nêu ra đây để giả sử có nhà tuyển dụng nào đó... Tongue). Có 1 số quy tắc (kinh nghiệm), nó thiên về nguyên lý (triết lýWink chung chung về lập trình mà mình chia sẻ dưới đây. Nó có thể đúng, có thể sai, nhưng nếu bạn cũng chia sẻ một cách nhìn như dưới đây, hoặc phản đối, hoặc muốn trolling và ném gạch, bạn có thể để lại còm men bên dưới. Nó sẽ khá hữu ích nếu bạn bắt đầu với máy tính.


Nguyên tắc thứ nhất. Sử dụng ngôn ngữ tự nhiên.


Có rất nhiều bạn xài Java/C# nhưng vẫn sử dụng "ngôn ngữ máy". Điều này không hề hài hước, mà có thật, nó tồn tại và làm khó khăn cho chính bạn và những người maintain mã nguồn của chính bạn. Điều này xảy ra vì bạn luôn muốn cố gắng "bắt chước", "theo đuổi" cái máy tính, và tại vì từ thuở sơ khai của lập trình, máy tính không đủ thông minh để hiểu chính bạn, do vậy bạn phải thay đổi theo cách suy nghĩ của máy tính.


Máy tính, vốn là công cụ, nó sinh ra để phục vụ con người, nó thay đổi để hiểu chúng ta hơn. Chúng ta không nên làm điều ngược lại, cố gắng thay đổi bản thân mình để phục vụ một công cụ do chúng ta tạo ra.


Mình đơn cử như việc thêm vào prefix của biến, rất khá phổ biến.


m_iNumberOfLines 


Mình không hề phê phán cách đặt tên biến này, nhưng đó là một minh chứng bạn đã thay đổi ngôn ngữ của mình để theo đuổi cái máy tính. Vâng bạn có thể theo đuổi cách đặt tên biến này. Nhưng, trong "ngôn ngữ tự nhiên" mà mình muốn nói tới, bạn chỉ đơn giản đặt một cái tên tự nhiên, ưa nhìn, sexy, .. bản thân cái tên number of lines đã biểu thị cho ý nghĩa của biến, bạn không cần phải có thêm "m" hoặc "i" để hiểu là nó thuộc cái giống gì. Trong mọi trường hợp khác, trừ phi bạn lười nhác hoặc cái tên không đủ ý nghĩa của cái biến mình đang cần xài, bạn thêm prefix hoặc suffix cho biến, điều này y chang như trong cách nói chuyện hàng ngày của bạn:


"(m) (g) con bồ của thằng A nó có bầu rồi (s) (p) tụi mày ạ. (m) (t) cái thai là của tao Unhappy("


Đó chỉ là đơn cử 1 trong số những điều mà lập trình viên ta hay làm, sử dụng "ngôn ngữ máy" trong lúc lập trình. Việc sử dụng ngôn ngữ tự nhiên, gần gũi, khiến lập trình viên tư duy 1 cách tự nhiên, không bị giới hạn bởi các quy tắc cứng nhắc của máy tính. Điều này còn khiến code của bạn dễ đọc hơn, thậm chí 1 người không biết gì về lập trình, nhưng có tư duy ngôn ngữ tốt, họ vẫn có thể đọc được code của bạn. Bạn trở thành pro lúc nào không hay.


Ngược lại của ví dụ trên là một lập trình viên viết code mà chỉ có máy mới hiểu. Còn "người bình thường" thậm chí chính họ cũng không hiểu được là mình đang viết cái gì, mọi thứ họ quan tâm là "kết quả". Họ chỉ quan tâm tới kết quả trên màn hình, nhưng thật kỳ lạ, họ hiếm khi học hoặc nhớ được gì trong quá trình làm việc. Và thường, họ không phải là lập trình viên chuyên nghiệp, họ đơn độc, và một ngày nào đó bạn đọc báo thấy họ bị giết bởi một lập trình viên khác, người vừa được giao nhiệm vụ bảo trì cho mã nguồn mà họ viết cách đó ít tuần.


Nên nhớ, một lập trình viên chuyên nghiệp viết code không cần phải viết comment, họ chỉ viết document cho code, bởi vì bản thân code của anh ta đã là comment tốt nhất.


Ví du:      C = A + B; // C bằng tổng của A và B.


Nguyên tắc thứ hai. Không cẩu thả.


Bạn thấy đó, việc cẩu thả trong lập trình có thể giết chết bạn. Bạn có thể chết theo trường hợp ở trên, rất xứng đáng. Nhưng bạn có thể chết sớm hơn, một cơn đau đầu nhẹ trong lúc OT ở tháng thứ ba, lúc mà bạn đang suy nghĩ không biết mình đang tìm cái gì ở tháng thứ nhất, rồi sau đó bạn không biết gì nữa. Khám nghiệm tử thi cho thấy bạn bị đột quỵ trong giờ làm việc, Producer xin nghỉ dài hạn, người ta đưa một lập trình viên khác thế chổ cho bạn. Bạn bè của bạn sẽ tới viếng bạn và mọi người sẽ bảo bạn là một lập trình viên chuyên nghiệp, làm việc chăm chỉ. Đồng nghiệp sẽ đi cho bạn một ít tiền, một ít vẫn còn nguyền rủa trong đám tang của bạn vì dự án vẫn chưa kết thúc, mà code của bạn họ đọc không có hiểu. Nhưng mà bạn đâu có biết được điều đó...


Bạn đã có thể có một kết thúc tốt đẹp hơn, nếu bạn chăm chút một tí vào code. Việc coding sao cho đẹp, ngay ngắn thẳng hàng không hề khó. Nó giống như việc bạn tập xe đạp, một khi bạn đã quen tuân thủ các quy tắc về coding style, bạn sẽ không bao giờ coding một cách cẩu thả nữa. Để bắt đầu, mình khuyên bạn viết một lá thư xin việc bằng tiếng Anh cho công ty mà bạn yêu thích xài MS Word. Cố gắng làm sao cho lá thư xin việc của bạn ngay ngắn, chỉnh tề và thu hút nhất. Và đừng quên, không được cẩu thả.


Nguyên tắc thứ ba. Luôn suy nghĩ.


Ngay khi bạn nghĩ ra một khái niệm, một biến hoặc một hàm, bạn ngay lập tức phải nghĩ ra ý nghĩa của nó. Bạn sử dụng nó làm gì? Nó có thực sự cần thiết hay không? Có phương pháp nào tốt hơn hay không? Nó ở đâu trong thiết kế chương trình? Làm thế nào để đặc tả nó? 


Sau khi trả lời tất cả các câu hỏi, bạn bắt đầu tìm cho nó một cái tên phù hợp. Thông thường bạn sẽ rất dễ dàng tìm một cái tên cho nó. Một cái tên mang ý nghĩa thực sự trả lời được tất cả các câu hỏi trên. Nhưng nếu bạn thực sự không thể suy nghĩ ra 1 cái tên đơn giản để mô tả cho nó, điều đó có thể là do bạn không thật sự cần khái niệm đó trong chương trình, do sự thiếu logic trong suy nghĩ của bạn và điều bạn cần làm là bỏ đi khái niệm đó.


Hãy nhớ lại khi bạn bảo vệ đồ án tốt nghiệp, thầy cô sẽ hỏi bạn "biến này/hàm này/lớp này" dùng để làm gì? Tại sao lại phải xài? Tại sao không dùng...


Nguyên tắc thứ tư: DRY - Don't Repeat Yourself.


Một khái niệm tồn tại trong chương trình phải là duy nhất. Thật rắc rối nếu bạn định nghĩa 1 khái niệm trong chương trình ở nhiều nơi khác nhau. Hãy biết cách tái sử dụng những thứ mà bạn đã viết. Hãy viết chương trình một cách đơn giản nhất, mọi khái niệm được định nghĩa, mọi đoạn code bạn viết là duy nhất trong chương trình.


"Bạn gái là bạn gái và vợ lạ vợ". Nhưng nếu bạn đã kết hôn, thì không nên có thêm khái niệm bạn gái. Smile


Cuối cùng, đừng suy nghĩ là mình đang viết code cho máy tính, hãy viết code và coi đó là 1 tác phẩm mà bạn sẽ chia sẻ cho bạn bè và cộng đồng.


Coding là một nghệ thuật, và bạn chính là người nghệ sĩ.


Hết.



Chọn phong cách cho bạn

Trần Thiện KHiêm
Nhưng là điều mình rất tâm đắc và tin tưởng.
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Hà Quang Tú
Comment là cả một nghệ thuật đấy
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
La Minh Truong
Viết code không comment là thói wen của những người có suy nghĩ code của mình comment làm gì, rất giống mềnh =]]. Nhưng đến khi thằng khác port nó sẽ tốn công ngồi đọc xem cái function đó làm gì, comment vẫn tốt hơn, đỡ tốn thời gian đọc code ^^
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Le Viet Bach
Quy tắc nữa: code và comment = tiếng Anh, ưu tiên American spelling. Ghét nhất mấy ông code + comment bằng tiếng mán. Hồi xưa ngồi đọc cái open source project nào đó mà thấy variable name + comment toàn tiếng Đức -.-.

Còn vụ prefix thì tùy thôi. Những cái có lý và có tác dụng thì dùng. Hungarian nota...
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Trần Phong Phú
Rất thích những tư tưởng của Lê Việt Bách . I like you so much!
  • tháng 6 18, 2012
  • ·
  • Thích
  • ·
Yin Yang
Trước đây cũng nghĩ như bạn Khiêm: "Good code is its own best documentation". Nhưng giờ thì khác, comment giúp bạn có thể xác định nhanh được 1 đoạn code dài có mục đích làm gì. Cho dù code có rõ ràng đến đâu, cũng ko giúp người đọc hiểu nhanh = 1 dòng comment tốt.

Khi đọc code người khác, ko ai đủ ...
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Trần Thiện KHiêm
Nếu comment như Yingyang nói, về bản chất là tóm gọn nội dung của một hàm, một đoạn code, có thể viết trong document của code đó. Mình không coi trọng comment = code vì comment nó ko thực sự chính xác 100% và nó lặp lại những gì mình đã viết (= ngôn ngữ lập trình).
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Trần Thiện KHiêm
@Ying Yang: Theo mình thì đặt comment vào giữa code khiến xao nhãng và mất thẩm mỹ. Đặt ở đầu như document cho code đó khiến cả người quan tâm tới code và người không quan tâm tới code đều có thể đọc được, và có thể generate ra 1 tài liệu nữa.
  • tháng 6 17, 2012
  • ·
  • Thích
  • ·
Lê Hoàng Tiến
Mới đầu đọc tiêu đề cũng hay, nhưng đọc vô trong thấy hơi kỳ, mình không có tư cách phê phán, mình chỉ nói ý kiến chủ quan thôi. Mình chỉ mới đọc phần đầu về "Ngôn ngữ tự nhiên" thì đã cảm thấy hơi kỳ rồi. Đơn giản, mình nghĩ có thêm 5-10 năm nữa mình cũng sẽ đặt tên theo kiểu đó, bởi vì, mình không...
  • tháng 6 18, 2012
  • ·
  • Thích
  • ·
Trần Thiện KHiêm
Cám ơn bạn đã góp ý. Nếu bạn thật sự không nhớ, hãy để máy tính nhớ giúp bạn Kiếm 1 cái IDE tốt hơn. Theo mình, viết tự nhiên vẫn hay nhất, nó giúp tư duy của mình được "tự nhiên" và không bị ép buộc, từ đó suy nghĩ cũng dễ dàng hơn. Có nhiều đoạn code mà dù giải quyết 1 vấn đề đơn giản mà nhìn vào...
  • tháng 6 19, 2012
  • ·
  • Thích
  • ·
La Minh Truong
Mỗi người code mỗi khác, thằng A nhìn code thằng B thường sẽ không thích và ngược lại. Nói chung nếu chỉ code cho một mình mình thì code sao cũng được, còn nếu 1 cái dự án mà 5-10 người code thì phải có sự thống nhất chung về nhiều thứ nếu không nhìn vô cái source ngứa mắt lắm

Chẳng hạn

- Khai báo biế...
  • tháng 6 18, 2012
  • ·
  • Thích
  • ·
Trần Thiện KHiêm
Quan trọng ở đây, mình muốn tất cả mọi người tiến tới 1 chuẩn chung bạn ạ, 1 triết lí chung nhất.
  • tháng 6 19, 2012
  • ·
  • Thích
  • ·
Hà Quang Tú
Mình cũng gét nhất ông nào bỏ cái {} . Ghét cả mấy ông viết tắt các bước nữa . 1 dòng mà new mấy lần . Ví dụ : A a = new A(new B(new C));
  • tháng 6 18, 2012
  • ·
  • Thích
  • ·
Hoang Thanh Tung
Tìm hiểu về nguyên tắc DRY thì thấy bài này
Đọc thì k đồng tính cái đầu tiên vì nó là chuẩn do nơi làm việc, môi trường .... còn đó là quan điểm cá nhân của bạn và nó cũng chỉ nên áp dụng cho cá nhân thôi.
Vẫn thích nhất cái DRY.
  • tháng 1 19, 2013
  • ·
  • Thích
  • ·
Captcha Challenge