Hướng dẫn camelcase javascript la gì

Trong lập trình quy chuẩn đầu tiên cần đưa ra là quy chuẩn cho việc đặt tên. Có hàng tỉ thứ cần đặt tên trong lập trình, nói chơi vậy thôi chứ phân loại ra khoảng hơn chục thôi à, ví dụ như tên Class, tên biến, tên phương thức, tên thuộc tính... Có 3 chuẩn để đặt tên là underscore, camelCase và PascalCase.

Nội dung chính

• Các quy chuẩn đặt tên thông thường
• Lời kết
• 1. Bao nhiêu là đủ, indent với tab hay space
• 2. Đặt tên theo camelCase hay snake-case
• 3. Vị trí dấu ngoặc
• 4. Nhập gia tùy tục thế nào cho đúng
• Tổng kết

• underscore: sử dụng dấu gạch chân giữa các từ, tất cả các từ đều viết thường, ví dụ: $this_is_my_variable.
• camelCase: giống như cách viết của nó, từ đầu tiên viết thường, các từ tiếp theo viết hoa chữ cái đầu, ví dụ $thisIsMyVariable.
• PascalCase: viết hoa tất cả các chữ cái đầu, ví dụ $ThisIsMyVariable.

Các quy chuẩn đặt tên thông thường

Sau đây là một số quy chuẩn đặt tên thường dùng trong dự án:

• Tên lớp đặt theo PascalCase, ví dụ: UserClass, CategoryClass...
• Tên hàm và phương thức sử dụng camelCase, ví dụ getUser, getCategory...
• Tên biến cũng sử dụng camelCase $loginUser, $categoryList...
• Tên hằng số thì đặc biệt, viết hoa hết và cách nhau bởi dấu gạch dưới DISCOUNT_PERCENT, LIMIT_RATE...
• Tên bảng, tên cột trong Database sử dụng underscore và sử dụng danh từ số nhiều, ví dụ bảng oauth_clients, oauth_refresh_tokens.
• Tên phần tử trong HTML, ví dụ khi bạn sử dụng Vue.js, React... tạo ra thì nó sẽ có dạng KebabCase, ví dụ .

Đặt tên là để gợi nhớ, ví dụ khi gọi đến tên của bạn là người ta biết ngay đó là bạn mà không nhầm sang người khác, đặt tên trong lập trình cũng vậy cần phải tường minh. Trước đây tôi có một người bạn trong cùng cơ quan đặt tên các biến khá thú vị: $heheheeeee, $hihiiiiii... vãi cả nón, khi đọc code bò lăn ra cười, nói vui vậy thôi chứ như vậy là không nên, không thể hiểu được các biến này dùng làm gì, đặc biệt hơn nữa là khi xử lý qua lại đánh tên các biến này khó vãi, chắc phải copy cho chắc ăn.

Lời kết

Bạn nên tập thói quen đưa ra một quy chuẩn đặt tên trong lập trình của riêng mình, như vậy khi làm việc theo nhóm các thành viên khác có thể dễ dàng đọc được code của bạn. Hơn nữa, các thư viện mã nguồn mở hiện nay đều tuân thủ theo những quy ước đặt tên, nếu bạn không muốn mình tách rời với cộng đồng hãy tuân thủ theo "pháp luật".

CÁC BÀI VIẾT KHÁC

Trong mỗi dự án, Frontend Dev có vai trò như lính đánh thuê, cũng giống như người ta thường nói "làm dâu trăm họ". Để hài lòng với mọi gia đình đặc biệt là những "bà mẹ chồng khó tính", chị em chúng ta cần học theo kinh nghiệm đúc kết từ những bậc tiền bối.

1. Bao nhiêu là đủ, indent với tab hay space

Thông thường convention mà các lập trình viên lấy làm chuẩn sẽ là 2 hoặc 4 space tùy theo ngôn ngữ hoặc rules dự án. Bạn có thể tham khảo code style PSR-2.

Khi code bạn thường dùng gì để thụt đầu dòng (indent)?

Có người thích dùng tab, người khác lại dùng 2 hoặc 4 dấu space để thụt dòng. Bên cạnh việc không thống nhất là bao nhiêu space còn có sự tranh cãi giữa dùng tab và dùng space. Vì sao lại xảy ra tình trạng tranh cãi, ai thích dùng gì thì dùng chứ. Đó là vì có ý kiến cho rằng gõ 2 dấu cách mới là code chuẩn, còn dùng tab thì không. Nên dùng 2 spaces hay dùng tab?

Câu trả lời là dùng space. Mỗi editor sẽ định nghĩa độ dài của tab khác nhau nên rất lộn xộn về code. Tuy nhiên các editor hiện tại đã support việc convert 1 tab bằng 2 hoặc 4 space.

2. Đặt tên theo camelCase hay snake-case

Đây là 2 dạng naming convention phổ biến, cả 2 loại này sẽ xuất hiện trong cùng 1 project của bạn. Tuy nhiên dùng ở đâu là phù hợp?

- camelCase

Nhìn vào cách viết, chắc các bạn cũng đã đoán được đây là gì. CamelCase là kiểu viết code theo dạng lạc đà (u bướu) mà chắc ai cũng dễ dàng nhận ra khi mới bắt đầu học code. Các chữ cái đầu từ đều được viết hoa. Style này dùng đặt tên biến, tên function... thường sẽ xuất hiện ở những ngôn ngữ lập trình: java, javascript, php...

var productItems;

function checkNumber() {};

- snake-case

Đây là cách viết code dùng dấu gạch dưới để phân cách các từ, tất cả từ đều được viết thường. Tuy là người sợ rắn nhưng mình rất thích cách viết này vì nó rõ ràng. Thông thường trong HTML/CSS để đặt tên class/id bạn sẽ tuân theo style này. Nếu bạn đã biết về BEM, bạn cũng sẽ thấy đây là ứng dụng của style này.

/* CSS */
#product-items {}

.section-banner {};
.section-banner__wrap {};

<div id="product-items">div>

<div class="section-banner">
  <div class="section-banner__wrap">div>
div>

3. Vị trí dấu ngoặc

Vũ trụ thường có 2 kiểu người, bạn thuộc kiểu nào dưới đây:

// same line formatting
function ahihi() {

}

// next line formatting
function ahihi()
{

}

Same line formatting:

• Dễ đọc hơn vì dấu mở ngoặc ở cạnh function name.
• Gọn gàng hơn, không làm số dòng phình to.
• Dễ dàng phân biệt và tìm dấu ngoặc đóng.

Next line formatting:

• Dễ đọc nhưng sẽ làm phình to số dòng code.
• Ngược lại, dễ dàng tìm dấu ngoặc đóng và cả hai đều cùng 1 vị trí.

Nên viết theo dạng same line formatting vì hầu như convention nào cũng tuân theo styled này. Nó cũng thuận tiện hơn khi bạn collapse method trong các editor.

4. Nhập gia tùy tục thế nào cho đúng

Mỗi dự án sẽ có một convention khác nhau. Để dễ dàng tuân theo những convention này và cũng có cảnh báo nếu mình "sa cơ lỡ bước".

Nếu dùng những editor như VSCode, Sublime text, Atom... bạn nên cài extension của những rules:

• EditorConfig: thống nhất style của editor và project
• ESLint: bắt những lỗi viết code javascript (khai báo thừa biến, function... sai convention...)
• Stylelint: bắt những lỗi thuộc về CSS/SASS

Ví dụ mình dùng VS Code, mình sẽ cài extension EditorConfig for VS Code. Khi bạn import project, extension sẽ đọc file .editorconfig để cấu hình workspace editor phù hợp với convention.

Đây là ví dụ đoạn config của file .editorconfig

# EditorConfig is awesome: http://EditorConfig.org

# Đây là file thiết lập gốc
root = true

# Newline theo chuẩn Unix và luôn có dòng mới ở cuối file
[*]
end_of_line = lf
insert_final_newline = true

# Đối với các tập tin Python thì dùng 4 khoảng trắng
[*.py]
indent_style = space
indent_size = 4

# Với các tập tin JavaScript thì dùng tab, không quy định size
[*.js]
indent_style = tab

# Nhưng với các tập tin JavaScript trong thư mục lib thì dùng 2 khoảng trắng
[lib/**.js]
indent_style = space
indent_size = 2

# Đối với tập tin package.json hoặc .travis.yml thì dùng 2 khoảng trắng
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

Tương tự, bạn cũng có thể tìm hiểu về rules cũng như cách config của ESlint và Stylelint.

Tổng kết

Hiện nay ngôn ngữ lập trình và các framework ngày càng trở nên phong phú. Nhưng về logic, convention thì đều có điểm chung. Để teamwork tốt và tạo cho bản thân mình một nề nếp "sạch sẽ", chúng ta nên có thói quen viết code "best practices" nhờ convention. Chúc các bạn có một source code sạch sẽ và review những dòng code của người khác thật dễ nhìn.

Một số convention mà mình thường làm chuẩn:

• CSS/SASS: https://github.com/airbnb/css
• Javascript: https://github.com/airbnb/javascript
• React: https://github.com/airbnb/javascript/tree/master/react
• BEM - naming convention: http://getbem.com/

Tool support editor:

• EditorConfig - config convention project with editor: https://editorconfig.org/
• Eslint - validate Javascript : https://eslint.org/
• Stylelint - validate CSS/SASS: https://stylelint.io/