Hỏi - đáp Nơi cung cấp thông tin nghề nghiệp và giải đáp những thắc mắc thường gặp của bạn

Những điểm đáng lưu ý từ Google’s JavaScript Style Guide

Cho những ai chưa biết, Google đã cho ra mắt Hướng dẫn về phong cách viết code Javascript chỉ ra cách (Google tin là) sẽ khiến code viết ra sạch sẽ và dễ hiểu hơn.

Đây là những hướng dẫn để duy trì style phù hợp trong source file chứ không phải là những quy tắc khó hoặc nhanh để viết code Javascript khả dụng. Điều này khá phù hợp với Javascript – một ngôn ngữ linh hoạt cho phép nhiều sự lựa chọn style phong phú.

Google và Airbnb có 2 trong những Style guide nổi tiếng nhất. Các bạn nên xem qua cả 2 nếu bạn đang dành nhiều thời gian để viết code Javascript.

Bên dưới là 13 điều tác giả nghĩ là thú vị và thích hợp nhất từ Google’s JS Style Guide. Họ nhắc đến mọi thứ từ những vấn đề được tranh cãi gay gắt (như tab vs space, dấu chấm phẩy..) đến một vài vấn đề chuyên biệt khác khiến tác giả phải ngạc nhiên. Họ chắc chắn đã thay đổi cách code JS sau này.

Với mỗi quy định tác giả sẽ tóm tắt lại, theo sau đó là một dòng trích dẫn mô tả chi tiết quy định đó trong Style Guide. Những nơi cần thiết, tác giả cũng sẽ cũng sẽ cung cấp ví dụ thực tiễn và so sánh nó với code không viết theo hướng dẫn để các bạn có một góc nhìn tổng quan hơn.

Sử dụng space chứ đừng dùng tab

Bên cạnh những dãy kết thúc dòng, ký tự space theo bảng ASCII (0x20) là ký tự khoảng trắng duy nhất xuất hiện bất cứ nơi nào trong source file. Điều này ngụ ý rằng ... ký tự Tab không được sử dụng để canh lề.

Hướng dẫn này sẽ chỉ bạn cách sử dụng 2 lần phím space (mà không phải 4) để canh lề:

// bad
function foo() {
∙∙∙∙let name;
}

// bad
function bar() {
∙let name;
}

// good
function baz() {
∙∙let name;
}

Dấu chấm phẩy (;) là bắt buộc

Mỗi câu lệnh đều phải kết thúc bằng dấu ;

Việc chèn tự động dấu ; đều bị cấm

Mặc dù tôi (- tác giả) không tưởng tượng nổi tại sao nhiều người lại bất đồng với ý kiến này, việc sử dụng dấu ; trong Javascript đang dần trở thành một cuộc chiến “space vs tab” mới. Google chắc chắn đang chọn sử dụng dấu ;

// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
jedi.father = 'vader';
});

Hãy (tạm) chưa sử dụng ES6 Module

Hãy (tạm) chưa sử dụng các module ES6 ( tức là các từ khóa xuất nhập) bởi vì ngữ nghĩa của chúng vẫn chưa được quyết định xong. Lưu ý là điều này sẽ được xem xét lại ngay khi ngữ nghĩa đã được định chuẩn.

// Don't do this kind of thing yet:
//------ lib.js ------
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';

Căn ngang không được khuyến khích (nhưng cũng không bị cấm)

Điều này được cho phép nhưng Google Style không khuyến khích nó. Thậm chí việc duy trì căn ngang ở những nơi đã từng được căn ngang còn không bắt buộc.

Căn ngang là việc thêm vào code của bạn những khoảng trống để đảm bảo các token xuất hiện trực tiếp ngay bên dưới các token khác của dòng trước.

// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};

Đừng sử dụng var nữa

Khai báo tất cả các biến cục bộ với const hoặc let. Sử dụng const theo mặc định, trừ khi một biến cần được gán lại. Không được sử dụng từ khóa var.

Tôi vẫn còn thấy mọi người dùng var trong các mẫu code trên StackOverflow và các nơi khác. Tôi không thể nói rằng vẫn có những người ngoài kia đang sử dụng nó hay đó cũng chỉ là trường hợp của một thói quen đang chết dần thôi.

// bad
var example = 42;
// good
let example = 42;

Nên sử dụng arrow function

Arrow function cung cấp một cú pháp ngắn gọn và sửa nhiều khó khăn khi viết cú pháp. Nên sử dụng arrow function thay vì function keyword, đặc biệt là cho các nested functions.

Thú thực là tôi chỉ nghĩ là arrow function tuyệt vời vì chúng nhìn nhìn ngắn gọn và dễ chịu hơn, hóa ra thì chúng giải quyết được rất nhiều vấn đề.

// bad
[1, 2, 3].map(function (x) {
const y = x + 1;
return x * y;
});

// good
[1, 2, 3].map((x) => {
const y = x + 1;
return x * y;
});

Sử dụng template string thay vì concatenation

Sử dụng các template string (được phân định bằng `) thay vì các concatenation string phức tạp, đặc biệt khi có nhiều string literal. Teamplate string có thể trải rộng trên nhiều dòng.

// bad
function sayHi(name) {
return 'How are you, ' + name + '?';
}

// bad
function sayHi(name) {
return ['How are you, ', name, '?'].join();
}

// bad
function sayHi(name) {
return `How are you, ${ name }?`;
}

// good
function sayHi(name) {
return `How are you, ${name}?`;
}

Không sử dụng các dòng liên tục đối với các chuỗi dài

Không sử dụng các dòng liên tục ( nghĩa là, kết thúc 1 dòng bên trong 1 string literal với một \) trong bất kể cả template string literals hay bình thường. Mặc dù ES5 cho phép điều này nhưng nó có thể dẫn tới các lỗi nếu bất kỳ khoảng trắng nào theo sau dấu gạch chéo và ít rõ ràng hơn so với người đọc.

Thật thú vị và quy định này Google và Airbnb lại không đồng ý với nhau (theo hướng dẫn Airbnb).

Trong khi Google khuyến khích nối lại các chuỗi dài hơn (như bên dưới) thì Airbnb lại nhấn mạnh rằng không nên làm gì cả và cho phép các chuỗi cứ kéo dài đến khi nào cần.

// bad (sorry, this doesn't show up well on mobile)
const longString = 'This is a very long string that \
far exceeds the 80 column limit. It unfortunately \
contains long stretches of spaces due to how the \
continued lines are indented.';
// good
const longString = 'This is a very long string that ' +
'far exceeds the 80 column limit. It does not contain ' +
'long stretches of spaces since the concatenated ' +
'strings are cleaner.';

“for..of” được khuyến khích hơn “for loop”

Với ES6, ngôn ngữ bây giờ đã có 3 loại khác nhau của for loops. Tất cả đều có thể sử dụng, mặc dù for-of loops nên được sử dụng khi có thể

Điều này có vẻ hơi kì lạ nếu bạn hỏi tôi, nhưng tôi nghĩ mình vẫn nên đề cập đến bởi vì thực thú vị là Google tuyên bố có một dạng tốt hơn của for loop

Tôi luôn bị ấn tượng rằng for... in loops tốt hơn cho objects, trong khi for... of thích hợp hơn với các giá trị trong mảng (array). Đây là một trường hợp điển hình của “việc nào công cụ nấy”.

Tuy Google không thực sự chỉ ra mâu thuẫn với ý tưởng này nhưng vẫn thật thú vị khi biết họ có sở thích sử dụng loop này hơn.

Đừng dùng eval()

Đừng dùng eval hoặc là Function(…string) (ngoại trừ code loader). Những tính năng này khá nguy hiểm và không hoạt động trong môi trường CSP.

Trang MDB cho eval() thậm chí còn có 1 phần gọi là “ Đừng sử dụng eval”.

// bad
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
eval( 'var result = obj.' + propName );
// good
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

 

Các hằng số phải được đạt tên trong ALL_UPPERCASE, tách ra bởi dấu gạch dưới

Tên các hằng số sử dụng CONSTANT_USE: tất cả các kĩ tự phải viết in hoa với các từ cách nhau bởi dấu gạch dưới.

Nếu bạn chắc chắn rằng một biến không nên thay đổi, bạn có thể chỉ ra điều này bằng cách viết hoa tên hằng số. Điều này làm sự bất biến của hằng số trở nên hiển nhiên khi nó được sử dụng xuyên suốt code của bạn.

Lưu ý là quy định này không áp dụng với những hằng số function-scoped. Trong trường hợp này, nó nên được viết bằng camelCase.

// bad
const number = 5;
// good
const NUMBER = 5;

Một biến trên một declaration

Mỗi một local variable declaration chỉ khai báo 1 biến: những khai báo như let a = 1, b = 2 không nên sử dụng.

// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;

Sử dụng ‘ chứ không phải “

Các string literal thông thường thường được phân cách bằng dấu ‘ hơn là dấu ‘’

Tips: nếu một string có chứa dấu ‘. Hãy xem xét sử dụng một teamplate string để tránh phải escape.

// bad
let directive = "No identification of self or mission."
// bad
let saying = 'Say it ain\u0027t so.';
// good
let directive = 'No identification of self or mission.';
// good
let saying = `Say it ain't so`;

Ghi chú cuối cùng

Như tôi đã nói ngay từ đầu, đây không phải là mệnh lệnh. Google chỉ là một trong những công ty công nghệ lớn và những điều trên chỉ là đề xuất thôi. Tuy nhiên, cũng phải nói rằng thực sự thú vị khi đọc các style recommnedation được xuất bản bởi các công ty như Google – nơi đã tuyển dụng được rất nhiều người tài năng – đã dành nhiều thời gian để viết các đoạn code tuyệt vời này.

Bạn có thể code theo những quy định này nếu bạn muốn theo sự chỉ dẫn viết source code của Google, tuy nhiên cũng sẽ có rất nhiều người không tán thành, và bạn cứ tự nhiên gạt hết đi nhưng thứ không phù hợp với bản thân.

Cá nhân tôi nghĩ là có nhiều trường hợp guidebook của Airbnb hấp dẫn hơn so với Google. Bất kể lập trường của bạn như thế nào, điều quan trọng nhất vẫn là phải giữ được 1 style thống nhất khi viết bất kì dòng code nào!

Via Medium