Don’t be that guys!. Viết functions sao cho tốt?

5184

Bài viết được sự cho phép của tác giả Kiên Nguyễn

Chuyện từ xửa xừa xưa, có anh chàng lập trình viên nọ rất thích viết FUNCTIONS, bất cứ khi nào có thể viết ra function mới thì anh ta đều viết. Đối với cha này thì functions là BẤT TỬ, là TUYỆT VỜI NHẤT.

functions-functions

Hàm, hàm khắp mọi nơi.

Tuy nhiên, không như e ve ri bo đi nghĩ, gã ta viết functions cực kì tệ hại, tên không rõ ràng, comment không có, dài lê thê tới cả vài trăm dòng.

Bỗng một ngày đẹp trời, anh ta đọc được Clean Code của Uncle Bob. Bùm, “mặt trời chân lý chói qua chim“. Anh ta đã ngộ ra được tứ trụ chân lý về function. Rút đi rút lại, đúc kết ra 4 bí kíp tàng kinh để truyền lại cho hậu thế, tránh lãng phí thời gian đi vào vết xe đổ của anh ta.

  1001 Tips: Con trỏ và hàm (Pointer & Function) trong C++
  5 điểm khác nhau giữa function thường và arrow function
So scare. Anh ngửi thấy mùi trong code của chú rồi nhé.

Don’t be that guys!. Begin

1. Functions Should Be Small – Function nên viết nhỏ thôi.

Đã qua rồi thời những function viết lê thê tới cả vài trăm dòng, comment rối rít. Lúc bạn viết, có thể bạn hiểu luồng thực thi, logic thực thi trong hàm. Tuy nhiên, 2 tháng sau, quay về nhìn lại, functions của bạn không khác gì một đống rác (khó hiểu, dài, thứ tự thực hiện lộn xộn).

Mình có đọc một bài viết, anh chàng nọ được TechLead của mình chỉ dạy một điều khá hay.

“If it (the function) requires a lot of effort, you stop and rethink your solution”

Nếu nó (functions) mất nhiều công sức để hoàn thành, bạn nên dừng lại và nghĩ lại về giải pháp của mình.

Bugs ở đâu ra?. Bugs tới từ sự hiểu nhầm, hiểu sai về một vấn đề nào đó. Nếu hàm viết quá dài, sẽ cực kì khó khăn để hiểu chính xác ý nghĩa của nó.

Functions viết nên nhỏ, nhưng tên mô tả thì nên lựa chọn cái dài. Người đọc sẽ dễ hiểu code của bạn. Source.

2. Function Should Be Clear – Function nên viết rõ ràng.

Đối với rule clear này, đơn giản ta có thể hiểu như là coding convention. Functions nên đáp ứng một số tiêu chí sau đây:

  • Không nên quá 100 dòng (functions should not be 100 lines long).
  • Không hầu như không bao giờ quá 20 dòng (functions hardly ever be 20 lines long).
  • Không nên có nhiều hơn 3 arguments. Việc có quá nhiều arguments sẽ làm funcitons trở nên khó hiểu, nếu arguments có cùng datatype thì còn có thể truyền nhầm giá trị nữa.
  • Tên gợi ý nghĩa. Việc đặt tên func1, func2 thật sự là một thảm họa với người đọc code. Một cái tên functions đầy đủ ý nghĩa sẽ chứng tỏ rằng bạn thực sự biết rõ method đang thực hiện việc gì. Ngoài ra, lúc maintanance, người reiview sẽ thầm cảm ơn bạn đấy.

3. Function Should Be Simple – Function nên viết đơn giản.

Nếu mày đọc bài và chưa có bạn gái, hãy cố kiếm lấy một cô. FACE TO FACE -> KISS -> XXX.

3 bước này đơn giản, lập trình còn đơn giản hơn, chỉ cần một trong ba bước. KISS.

KISS — Keep It Simple, Stupid

Giữ cho nó đơn giản. Thôi có văn hóa (không chửi bậy) =))

A shorter method is easier to read, easier to understand, and easier to troubleshoot. Refactor long methods into smaller methods if you can.

Một method ngắn thì dễ đọc, dễ hiểu và khắc phục sự cố. Hãy luôn có gắng refactor methods thành các methos nhỏ hơn nếu bạn có thể.

// Wtf, nhìn thôi là đã rối cả mắt.
// Function này đi handle lỗi.
// Cũng phải mất cả 20s mới nhìn ra.

function handleError(error) {
if not error A
if not error B
if not error C
// Làm cái m* gì đó.
else handle error C
else handle error B
else handle error A
}

Tại sao không viết.

// Nhìn cái hiểu luôn.
// Nó đi handle lỗi -> nhìn vào 3 cái return.
// Hiểu luôn.
function handleError(error) {
if error A
handle error A; return
if error B
handle error B; return
if error C
handle error C; return

// do something
}

Một ví dụ khác.

// Ơn chúa, function này cuối cùng thực hiện cái gì?
// Đọc code khó hiểu, khó sửa, dễ sửa sai.
public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
int nameCheck = SUCCESS;
if (someCondition) {
if (name != null && name != "") {
if (value != 0) {
if (perms.allow(name) {
// Do Something
} else {
nameCheck = PERM_DENY;
}
} else {
nameCheck = BAD_VALUE;
}
} else {
nameCheck = BAD_NAME;
}
} else {
nameCheck = BAD_COND;
}
return nameCheck;
}
public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
if (!someCondition)
return BAD_COND;

if (name == null || name == "")
return BAD_NAME;

if (value == 0)
return BAD_VALUE;

if (!perms.allow(name))
return PERM_DENY;

// Do something
return SUCCESS;
}

4. Function Should Have One Job – Function làm 1 việc thôi.

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.
Uncle Bob –Clean Code

FUNCTION chỉ nên thực hiện một việc. Chúng thực hiện cho tốt mỗi việc đó mà thôi – chú Bob.

Thực tế, những good programer đều tuân thủ quy tắc này. Mới đầu có vẻ nhàm chán, bởi một function chỉ thực hiện một công việc duy nhất. Tệ hơn, một số bạn dev với ra trường có thể nhìn bạn với ánh mắt đầy nghi hoặc (do có nhiều funcitons nhỏ).

Hầu hết, khi mới code được chừng 1 năm, các bạn sẽ cố gắng viết những function lớn, thực hiện nhiều việc. Nhiều tác vụ khó nhằn như phân trang,(paging) quản lý transaction ở model chỉ thực hiện với 2 hay 3 function.

Mình cũng vậy, ban đầu cứ nghĩ như vậy là sẽ tối ưu code. Nhầm, việc chia nhỏ function (đảm bảo chúng chỉ thực hiện MỘT VIỆC) sẽ cực kì hữu ích cho người khác khi đọc code, phát triển tính năng (feature) hoặc bảo trì (maintanance).

Bài viết gốc được đăng tải tại kieblog.vn

Có thể bạn quan tâm:

Xem thêm Việc làm IT hấp dẫn trên TopDev

RELATED ARTICLESMORE FROM AUTHOR