Nicholas C. Zakas là một trong các đại tôn sư JavaScript và front end hiện nay. Anh từng làm ở một số công ty nhỏ trước khi đến Yahoo! vào năm 2006. Ở đó, anh đóng vai trò Senior Front End Engineer rồi Principal Front End Engineer. Có thể xem Nicholas như thế hệ đàn em xuất sắc của Douglas Crockford, một bậc thầy JavaScript vĩ đại khác. Cả hai đều hoạt động sôi nổi, có đóng góp rất lớn trong việc hình thành thế giới front-end sống động như ngày nay. Hiện anh đang làm ở Box.com trong vai trò Principal Architect. Ngoài ra anh cũng tham gia biên soạn đặc tả EcmaScript, viết phần mềm và sách, cuốn mới nhất của anh có tiêu đề "Understanding ECMAScript 6", đang là sách gối đầu giường của nhiều developers, trong đó có tôi.
Năm 2011, Yahoo! YUI share 1 seminar chủ đề "Scalable JavaScript Application Architecture" của Nicholas trên YouTube và đã tạo thành hiệu ứng dữ dội, hàng loạt JavaScript framework mới ra đời hoặc được kiến trúc lại, bao gồm cả Angular, Ember và Backbone. Sau đó, chính anh cũng xây dựng T3.js, một framework nhỏ gọn, dùng cho hệ thống ứng dụng ở Box.
Năm 2012, Nicholas viết "Why Coding Style Matters" trên Smashing Magazine. Bài viết nhấn mạnh tầm quan trọng của coding theo convension. Theo anh, coding style không chỉ thể hiện tính chuyên nghiệp và tăng cường khả năng debug, mà còn ẩn chứa 2 yếu tố rất nhân văn khác: sự quan tâm đến người khác và trân trọng tương lai của chính mình.
Nay tạm dịch lại, mời các bạn xem chơi :)
Tại sao coding style quan trọng?
Thời còn đi học, tôi có một ông thầy rất nghiêm khắc tên là Maxey. Ông dạy các môn phức tạp như cấu trúc dữ liệu và kiến trúc máy tính. Ông giảng hay, dễ hiểu, nhưng cũng đặc biệt khó tính. Ông không chỉ dò code xem chạy đúng không mà còn bắt lỗi trình bày code nữa.
Nếu bạn quên comment vào những chỗ cần thiết, thậm chí nếu bạn gõ sai một hai từ trong comment, ông sẽ trừ điểm. Nếu code của bạn "bẩn" - so với tiêu chuẩn của ông ấy - ông ấy cũng trừ điểm. Thông điệp rất rõ ràng: chất lượng code không chỉ nằm ở chỗ nó chạy ra sao, mà còn phụ thuộc cách bạn trình bày nó nữa. Đó là những trải nghiệm đầu tiên của tôi về coding style.
Thế tóm lại coding style là gì?
Hiểu đơn giản, coding style là nói đến việc code của bạn trông ra làm sao. Chữ "bạn" ở đây tôi muốn nhấn mạnh là chỉ chính bạn, người đang đọc bài viết này. Coding style là chuyện hết sức cá nhân và ai cũng có thói quen riêng của mình. Bạn có thể tự khám phá style của bạn bằng cách xem lại những đoạn code mà bạn đã viết trước đây khi chưa học theo bất cứ style guide nào. Mỗi người có phong cách khác nhau vì cách họ tiếp cận các môn lập trình không hề giống nhau. Nếu bạn dùng các IDEs như Visual Studio để học code, bạn sẽ viết theo đúng cách editor đó quy định. Nếu bạn dùng các trình soạn thảo thuần văn bản, cách viết của bạn có thể tiến bộ dần theo những gì bạn thấy là dễ đọc.
Bạn sẽ sớm nhận ra rằng, ở mỗi ngôn ngữ khác nhau, cách viết code của bạn cũng thay đổi theo những chiều hướng khác nhau. Bạn có thể làm với JavaScript một kiểu, làm với CSS một kiểu khác. Chẳng hạn, bạn cho rằng chuỗi trong JavaScript nên dùng nháy kép, trong khi chuỗi bên CSS bạn vẫn dùng nháy đơn. Đây không phải chuyện hiếm gặp vì chúng ta có xu hướng chuyển đổi ngữ cảnh khi nhảy từ ngôn ngữ ngày sang ngôn ngữ khác. Nó là một bài tập thú vị trong việc tự quan sát bản thân.
Coding style được hình thành từ những quyết định nhỏ trong từng ngôn ngữ bạn sử dụng:
- Khi nào cần comment và comment thế nào?
- Thụt đầu dòng bằng tabs hay spaces (và bao nhiêu spaces)
- Sử dụng white space hợp lý
- Đặt tên biến và hàm rõ ràng
- Tổ chức và gom nhóm code
- Các patterns nên dùng và nên tránh
Đấy cũng chưa phải là tất cả, vì coding style có thể rất chi tiết như Google JavaScript Style Guide hay cũng có thể tổng quát hơn như jQuery Core Style Guidelines.
Đó là chuyện cá nhân
Tính chất cá nhân của coding style là một thách thức khi làm việc nhóm. Nhiều khi để tránh phải tranh luận dài dòng, người ta cố gắng trì hoãn việc xây dựng style guides với lý do không muốn "ngăn cản sự sáng tạo và tự do biểu hiện." Một số người nghĩ rằng đưa ra style guide cho team là ép buộc tất cả các developers vào cùng khuôn khổ. Một số developers kịch liệt chống đối khi phải code theo style guide, họ tin rằng sẽ không làm được việc nếu có ai đó cứ chỉ bảo họ phải viết code như thế nào.
Tôi thấy giống với tình huống một ban nhạc mới thành lập. Mỗi thành viên đều tin rằng cách chơi của họ là tốt nhất và cố gắng chơi theo cách riêng của họ. Nhưng không thể có âm nhạc ra hồn được trừ khi các thành viên nhất trí với nhau về nhịp độ, phong cách và cử ra người dắt nhịp. Nghe các nhóm nhạc trong trường học biểu diễn thì biết. Khó có thể làm được gì nếu mọi người không vận hành theo cùng một cách thức.
Đó là lý do tại sao tôi rất khuyến khích áp dụng style guide trong các nhóm phát triển phần mềm. Nếu bạn thấy khó để mọi người nhìn vấn đề theo cùng một cách thì hãy bắt đầu từ style guide. Khi mà ai cũng trình bày code giống nhau, bạn sẽ tránh được rất nhiều rắc rối tiềm ẩn.
Thân thiện: nghĩ đến người khác
Giao tiếp là thứ quan trọng nhất khi làm việc nhóm. Để công việc trôi chảy thì phải tương tác với nhau thật tốt. Các developers giao tiếp chủ yếu qua source code. Chúng ta dùng code để nói chuyện với phần mềm cũng như với các developers khác.
Cách bạn trình bày code không quan trọng đối với máy tính, nhưng lại rất quan trọng đối với các developer khác. Code viết rõ ràng thì đọc dễ hiểu hơn. Đã bao lần bạn mở source code của người khác mà việc đầu tiên là sửa lại định dạng lại theo cách của bạn? Đó là vì cách trình bày khiến bạn không hiểu được code. Khi ai đó viết code nhìn khác lạ, mọi người sẽ ngay lập tức phải phân tích một cách trực quan trước khi có thể hiểu được code đó làm gì. Khi ai đó viết code giống bạn, bạn sẽ cảm thấy dễ chịu và hiểu được chương trình một cách nhanh chóng.
Khi bắt đầu nghĩ về code như một phương tiện giao tiếp với các developer khác, cũng là lúc bạn nhận ra rằng viết code chính là một nghệ thuật. Code nên thể hiện rõ ràng mục đích của nó. Luôn nhớ rằng code mà bạn viết ra rồi sẽ được những người khác dùng lại. Bạn không chỉ tương tác với các thành viên trong team ở thời điểm hiện tại, mà còn cả những developers sẽ gia nhập sau này.
Mới đây tôi có nhận email từ một người đang làm việc với code do tôi viết từ 10 năm trước. Tôi giật mình kinh ngạc: code của mình vẫn còn được dùng trong sản phẩm. Anh ta cảm thấy thôi thúc phải mail cho tôi để bày tỏ rằng anh rất vui khi được làm việc với code của tôi. Tôi mỉm cười. Người đồng đội tương lai này thực sự tán thưởng coding style mà tôi đã theo đuổi.
Thận trọng: nhìn xa phía trước
Trong cuộc sống, phải tự biết mình. Trong coding cũng vậy. Dẫu sao bạn sẽ không bao giờ biết mình đủ rõ để nhớ lại những gì bạn nghĩ khi viết ra mỗi dòng code. Hầu hết developers đều trải qua những lúc nhìn lại code cũ của mình mà không hiểu tại sao viết thế. Không phải do trí nhớ bạn kém, chỉ là bạn đã phải giải quyết quá nhiều chi tiết nhỏ và không thể nào ghi nhớ từng chút một.
Nhưng nếu bạn viết code dựa trên một style guide, các thông tin đó sẽ được gửi gắm vào trong bản thân mỗi đoạn code. Chỉ cần bạn biết rõ khi nào và ở đâu nên để comments, patterns nào nên/không nên sử dụng, bạn đã tạo ra ở đó một con đường mòn cho tương lai khi cần quay lại tìm kiếm ý nghĩa của code.
Không gì thú vị hơn khi mở ra một đoạn code xưa cũ mà vẫn thấy nó như vừa được viết hôm qua. Bạn sẽ bắt nhịp nhanh chóng chứ không phải mất hàng giờ nghiền ngẫm lại logic của những đoạn code ấy.
Chris Epstein từng khuyên: “Hãy ân cần với tương lai của chính bạn.”
Sáng suốt: nhận biết lỗi nhanh chóng
Một trong những lý do phải áp dụng style guide là nó khiến cho lỗi trở nên dễ thấy. Style guides giúp developers thích nghi với các patterns nào đó. Và khi bạn đã quen với những patterns ấy rồi thì chỉ cần nhìn qua code một cái, bạn sẽ phát hiện ngay ra các patterns khác lạ. Những patterns khác lạ này có thể không gây lỗi, nhưng chúng đòi hỏi phải xem xét thật kỹ để đảm bảo không có gì sai.
Chẳng hạn như với cấu trúc "switch" trong JavaScript. Có một lỗi khá phổ biến là cho phép thoát khỏi case để đi vào case khác, ví dụ:
Nếu value là 1 thì chương trình sẽ đi qua case thứ nhất rồi nhảy vào case thứ 2. Nghĩa là cả doSomething và doSomethingElse cùng được gọi.
Câu hỏi đặt ra ở đây là: có lỗi gì không? Rất có thể developer quên một câu lệnh "break" trong case thứ nhất, nhưng cũng có khả năng developer cố ý cho kịch bản chạy cả 2 cases nếu value bằng 1. Chưa thể khẳng định được điều gì qua đoạn code trên.
Bây giờ giả sử bạn có JavaScript style guide nói như sau:
“Tất cả các cases trong câu lệnh switch phải kết thúc bằng break, throw, return, hay một comments chỉ dẫn một fall-through”.
Với style guide như thế, chúng ta xác định đây là một lỗi trình bày, tức là có thể có lỗi logic. Nếu chủ ý bạn muốn chương trình đi qua case thứ nhất, thì nên code như sau:
Nếu bạn muốn thoát khỏi switch ở case đầu tiên, nó nên kết thúc bằng "break". Ngoài ra, code đầu tiên không đúng với style guide, nghĩa là bạn cần kiểm tra thật kỹ kịch bản. Với thói quen này, bug sẽ được ngăn chặn rất sớm. Cái
Style guide giúp chỉ ra những đoạn code viết bừa bãi. Chỗ lợi hại nhất của style guides là: bằng cách định nghĩa thế nào là trình bày code đúng, bạn sẽ dễ dàng hơn trong việc nhận diện code sai và do đó, cả những lỗi tiềm ẩn trước khi chúng xảy ra.
Nếu bạn quên comment vào những chỗ cần thiết, thậm chí nếu bạn gõ sai một hai từ trong comment, ông sẽ trừ điểm. Nếu code của bạn "bẩn" - so với tiêu chuẩn của ông ấy - ông ấy cũng trừ điểm. Thông điệp rất rõ ràng: chất lượng code không chỉ nằm ở chỗ nó chạy ra sao, mà còn phụ thuộc cách bạn trình bày nó nữa. Đó là những trải nghiệm đầu tiên của tôi về coding style.
Thế tóm lại coding style là gì?
Hiểu đơn giản, coding style là nói đến việc code của bạn trông ra làm sao. Chữ "bạn" ở đây tôi muốn nhấn mạnh là chỉ chính bạn, người đang đọc bài viết này. Coding style là chuyện hết sức cá nhân và ai cũng có thói quen riêng của mình. Bạn có thể tự khám phá style của bạn bằng cách xem lại những đoạn code mà bạn đã viết trước đây khi chưa học theo bất cứ style guide nào. Mỗi người có phong cách khác nhau vì cách họ tiếp cận các môn lập trình không hề giống nhau. Nếu bạn dùng các IDEs như Visual Studio để học code, bạn sẽ viết theo đúng cách editor đó quy định. Nếu bạn dùng các trình soạn thảo thuần văn bản, cách viết của bạn có thể tiến bộ dần theo những gì bạn thấy là dễ đọc.
Bạn sẽ sớm nhận ra rằng, ở mỗi ngôn ngữ khác nhau, cách viết code của bạn cũng thay đổi theo những chiều hướng khác nhau. Bạn có thể làm với JavaScript một kiểu, làm với CSS một kiểu khác. Chẳng hạn, bạn cho rằng chuỗi trong JavaScript nên dùng nháy kép, trong khi chuỗi bên CSS bạn vẫn dùng nháy đơn. Đây không phải chuyện hiếm gặp vì chúng ta có xu hướng chuyển đổi ngữ cảnh khi nhảy từ ngôn ngữ ngày sang ngôn ngữ khác. Nó là một bài tập thú vị trong việc tự quan sát bản thân.
Coding style được hình thành từ những quyết định nhỏ trong từng ngôn ngữ bạn sử dụng:
- Khi nào cần comment và comment thế nào?
- Thụt đầu dòng bằng tabs hay spaces (và bao nhiêu spaces)
- Sử dụng white space hợp lý
- Đặt tên biến và hàm rõ ràng
- Tổ chức và gom nhóm code
- Các patterns nên dùng và nên tránh
Đấy cũng chưa phải là tất cả, vì coding style có thể rất chi tiết như Google JavaScript Style Guide hay cũng có thể tổng quát hơn như jQuery Core Style Guidelines.
Đó là chuyện cá nhân
Tính chất cá nhân của coding style là một thách thức khi làm việc nhóm. Nhiều khi để tránh phải tranh luận dài dòng, người ta cố gắng trì hoãn việc xây dựng style guides với lý do không muốn "ngăn cản sự sáng tạo và tự do biểu hiện." Một số người nghĩ rằng đưa ra style guide cho team là ép buộc tất cả các developers vào cùng khuôn khổ. Một số developers kịch liệt chống đối khi phải code theo style guide, họ tin rằng sẽ không làm được việc nếu có ai đó cứ chỉ bảo họ phải viết code như thế nào.
Tôi thấy giống với tình huống một ban nhạc mới thành lập. Mỗi thành viên đều tin rằng cách chơi của họ là tốt nhất và cố gắng chơi theo cách riêng của họ. Nhưng không thể có âm nhạc ra hồn được trừ khi các thành viên nhất trí với nhau về nhịp độ, phong cách và cử ra người dắt nhịp. Nghe các nhóm nhạc trong trường học biểu diễn thì biết. Khó có thể làm được gì nếu mọi người không vận hành theo cùng một cách thức.
Đó là lý do tại sao tôi rất khuyến khích áp dụng style guide trong các nhóm phát triển phần mềm. Nếu bạn thấy khó để mọi người nhìn vấn đề theo cùng một cách thì hãy bắt đầu từ style guide. Khi mà ai cũng trình bày code giống nhau, bạn sẽ tránh được rất nhiều rắc rối tiềm ẩn.
Thân thiện: nghĩ đến người khác
Giao tiếp là thứ quan trọng nhất khi làm việc nhóm. Để công việc trôi chảy thì phải tương tác với nhau thật tốt. Các developers giao tiếp chủ yếu qua source code. Chúng ta dùng code để nói chuyện với phần mềm cũng như với các developers khác.
Cách bạn trình bày code không quan trọng đối với máy tính, nhưng lại rất quan trọng đối với các developer khác. Code viết rõ ràng thì đọc dễ hiểu hơn. Đã bao lần bạn mở source code của người khác mà việc đầu tiên là sửa lại định dạng lại theo cách của bạn? Đó là vì cách trình bày khiến bạn không hiểu được code. Khi ai đó viết code nhìn khác lạ, mọi người sẽ ngay lập tức phải phân tích một cách trực quan trước khi có thể hiểu được code đó làm gì. Khi ai đó viết code giống bạn, bạn sẽ cảm thấy dễ chịu và hiểu được chương trình một cách nhanh chóng.
Khi bắt đầu nghĩ về code như một phương tiện giao tiếp với các developer khác, cũng là lúc bạn nhận ra rằng viết code chính là một nghệ thuật. Code nên thể hiện rõ ràng mục đích của nó. Luôn nhớ rằng code mà bạn viết ra rồi sẽ được những người khác dùng lại. Bạn không chỉ tương tác với các thành viên trong team ở thời điểm hiện tại, mà còn cả những developers sẽ gia nhập sau này.
Mới đây tôi có nhận email từ một người đang làm việc với code do tôi viết từ 10 năm trước. Tôi giật mình kinh ngạc: code của mình vẫn còn được dùng trong sản phẩm. Anh ta cảm thấy thôi thúc phải mail cho tôi để bày tỏ rằng anh rất vui khi được làm việc với code của tôi. Tôi mỉm cười. Người đồng đội tương lai này thực sự tán thưởng coding style mà tôi đã theo đuổi.
Thận trọng: nhìn xa phía trước
Trong cuộc sống, phải tự biết mình. Trong coding cũng vậy. Dẫu sao bạn sẽ không bao giờ biết mình đủ rõ để nhớ lại những gì bạn nghĩ khi viết ra mỗi dòng code. Hầu hết developers đều trải qua những lúc nhìn lại code cũ của mình mà không hiểu tại sao viết thế. Không phải do trí nhớ bạn kém, chỉ là bạn đã phải giải quyết quá nhiều chi tiết nhỏ và không thể nào ghi nhớ từng chút một.
Nhưng nếu bạn viết code dựa trên một style guide, các thông tin đó sẽ được gửi gắm vào trong bản thân mỗi đoạn code. Chỉ cần bạn biết rõ khi nào và ở đâu nên để comments, patterns nào nên/không nên sử dụng, bạn đã tạo ra ở đó một con đường mòn cho tương lai khi cần quay lại tìm kiếm ý nghĩa của code.
Không gì thú vị hơn khi mở ra một đoạn code xưa cũ mà vẫn thấy nó như vừa được viết hôm qua. Bạn sẽ bắt nhịp nhanh chóng chứ không phải mất hàng giờ nghiền ngẫm lại logic của những đoạn code ấy.
Chris Epstein từng khuyên: “Hãy ân cần với tương lai của chính bạn.”
Sáng suốt: nhận biết lỗi nhanh chóng
Một trong những lý do phải áp dụng style guide là nó khiến cho lỗi trở nên dễ thấy. Style guides giúp developers thích nghi với các patterns nào đó. Và khi bạn đã quen với những patterns ấy rồi thì chỉ cần nhìn qua code một cái, bạn sẽ phát hiện ngay ra các patterns khác lạ. Những patterns khác lạ này có thể không gây lỗi, nhưng chúng đòi hỏi phải xem xét thật kỹ để đảm bảo không có gì sai.
Chẳng hạn như với cấu trúc "switch" trong JavaScript. Có một lỗi khá phổ biến là cho phép thoát khỏi case để đi vào case khác, ví dụ:
switch(value) {
case 1:
doSomething();
case 2:
doSomethingElse();
break;
default:
doDefaultThing();
}
Nếu value là 1 thì chương trình sẽ đi qua case thứ nhất rồi nhảy vào case thứ 2. Nghĩa là cả doSomething và doSomethingElse cùng được gọi.
Câu hỏi đặt ra ở đây là: có lỗi gì không? Rất có thể developer quên một câu lệnh "break" trong case thứ nhất, nhưng cũng có khả năng developer cố ý cho kịch bản chạy cả 2 cases nếu value bằng 1. Chưa thể khẳng định được điều gì qua đoạn code trên.
Bây giờ giả sử bạn có JavaScript style guide nói như sau:
“Tất cả các cases trong câu lệnh switch phải kết thúc bằng break, throw, return, hay một comments chỉ dẫn một fall-through”.
Với style guide như thế, chúng ta xác định đây là một lỗi trình bày, tức là có thể có lỗi logic. Nếu chủ ý bạn muốn chương trình đi qua case thứ nhất, thì nên code như sau:
switch(value) {
case 1:
doSomething();
//falls through
case 2:
doSomethingElse();
break;
default:
doDefaultThing();
}
Nếu bạn muốn thoát khỏi switch ở case đầu tiên, nó nên kết thúc bằng "break". Ngoài ra, code đầu tiên không đúng với style guide, nghĩa là bạn cần kiểm tra thật kỹ kịch bản. Với thói quen này, bug sẽ được ngăn chặn rất sớm. Cái
Style guide giúp chỉ ra những đoạn code viết bừa bãi. Chỗ lợi hại nhất của style guides là: bằng cách định nghĩa thế nào là trình bày code đúng, bạn sẽ dễ dàng hơn trong việc nhận diện code sai và do đó, cả những lỗi tiềm ẩn trước khi chúng xảy ra.
Càng tỉ mỉ càng tốt
Khi giúp khách hàng xây dựng style guide, tôi thường được hỏi những chi tiết vụn vặt có thực sự quan trọng không? Câu trả lời là đúng và không đúng. Đúng vì cách trình bày code không thực sự quan trọng với máy tính. Không đúng vì những chi tiết nhỏ ấy sẽ giúp ích rất nhiều cho các developer phải bảo trì code. Hãy nghĩ thế này: nếu trong sách có một ký tự lỗi, bạn vẫn hiểu và không mất đi hứng thú với câu chuyện. Nhưng nếu có quá nhiều lỗi, bạn sẽ nhanh chóng cảm thấy khó chịu khi cứ phải giải mã ý tứ của tác giả.
Coding style giống hệt như vậy. Các bạn đang định nghĩa cách phát âm, quy tắc ngữ pháp cho mọi người theo. Style guide của các bạn có thể khá dài và chi tiết, không sao cả. Theo kinh nghiệm của tôi, một khi các nhóm bắt đầu code theo style guides, họ có xu hướng đi vào chi tiết vì điều đó giúp họ hiểu code và tổ chức code ngăn nắp hơn.
Tôi chưa từng thấy style guide nào quá mức chi tiết, nhưng tôi đã thấy một số được làm quá sơ sài. Cho nên điều quan trọng là nhóm phát triển style guide phải phối hợp chặt chẽ, thảo luận kỹ càng xem cái gì cần nhất, để đưa ra một nền tảng tốt cho style guide. Đừng quên rằng style guide là tư liệu sống. Nó sẽ tiếp tục được nâng cấp trong quá trình làm việc tập thể mọi người ngày càng hiểu nhau hơn và nắm rõ công việc hơn.
Công cụ hỗ trợ
Đừng ngại dùng các tools bắt bạn phải tuân thủ coding style. Web developers có rất nhiều tools hỗ trợ kiểm tra coding style, từ command line chạy khi build, đến các plugins gắn vào text editors. Đây là vài công cụ bạn có thể tham khảo:
Eclipse Code Formatter
Eclipse IDE có một tool tích hợp sẵn hỗ trợ định dạng code.
JSHint
Công cụ kiểm tra chất lượng code và trình bày code JavaScript.
CSS Lint
Công cụ kiểm tra chất lượng và trình bày CSS do Nicole Sullivan và tôi xây dựng.
Checkstyle
Một công cụ kiểm tra style guidelines trong Java code, dùng được cho nhiều ngôn ngữ khác.
Bạn có thể chia sẻ trong team các files cấu hình kiểm tra style guide. Ngoài ra, làm các công cụ tích hợp vào hệ thống continuous integration của bạn cũng là ý tưởng tốt.
Kết luận
Style guides là phần quan trọng khi viết code chuyên nghiệp. Dù bạn viết JavaScript hay CSS hay ngôn ngữ nào cũng vậy, cách trình bày code là phần không thể thiếu khi đánh giá chất lượng code. Nếu team hay dự án của bạn chưa có style guide, hãy bắt đầu ngay đi. Đây là một số style guides để các bạn tham khảo:
- jQuery Core Style Guidelines
- Google JavaScript Style Guide
- Google HTML/CSS Style Guide
- Principles of Writing Consistent, Idiomatic JavaScript
- Principles of Writing Consistent, Idiomatic CSS
- GitHub Style Guide (Ruby, HTML, CSS and JavaScript)
Tất cả mọi người trong team đều nên tham gia xây dựng style guide để tránh hiểu không đúng. Vả lại, có bỏ công sức vào mới thấy trân trọng. Hãy bắt đầu bằng cách để mọi người cùng đóng góp cho sự sáng tạo chung đó.
by Nicholas C. Zakas, October 25th, 2012, Smashsing Margazine
* Một năm sau bài viết này, Nicholas quyết định viết ESLint, và cũng có chia sẻ tại đây: ESLint: The Next-Generation JavaScript Linter
