Sau quãng thời gian dài làm việc với Ruby on Rails ở nhiều dự án khác nhau, mình đã đúc kết được một số kinh nghiệm coding mà nếu áp dụng theo, nó có thể giúp cho code của bạn dễ đọc và dễ dàng bảo trì hơn.
Việc rút gọn tên biến có thể làm cho đoạn code trở nên ngắn gọn nhứng bộ não của chúng ta lại dễ dàng ghi nhớ những từ có nghĩa hơn. Vì vậy, nếu bạn đặt tên biến là một từ vô nghĩa thì khi đọc code, bạn sẽ có cảm giác không thoải mái và khó hiểu:
Bad:
Good
Không nên thêm current context khi đặt tên cho variables, methods vì nó không cần thiết.
Bad:
Good:
Cái gì quá cũng không tốt và việc đặt tên methods hay class cũng vậy:
Bad:
Chỉ cần nhìn vào tên class chúng ta đã có thể biết được nội dung bên trong class đó là gì:
Nhưng có một vấn đề đó là action update user salary có thể sẽ không thay đổi nhưng thời gian update thì hoàn toàn có thể. Đến lúc đó, tên class sẽ phải thay đổi theo để phù hợp với yêu cầu và như thế thì không tốt chút nào.
Vì vậy, tên của methods hay class chỉ nên chứa đựng những thông tin ít thay đổi của biến hay class đó và không cần quá chi tiết:
Good:
Mục đích của việc sử dụng constant là để khi thay đổi, ta không phải tìm và sửa ở nhiều nơi, chứ không phải là để dùng constant đó ở nhiều nơi.
Bad:
Hãy tưởng tượng, sẽ thế nào nếu một ngày bạn muốn thay đổi giá trị per page lên thành 30 ở những nơi đang dùng PER_PAGE_20
?
Good:
Một trường hợp khác mà chúng ta thường mắc phải:
Bad:
Mọi thứ sẽ hoạt động bình thường nếu dữ liệu trả về ở index
giống với các thông tin permit
khi tạo user.
Nhưng rõ ràng, khi chỉ muốn thay đổi logic tạo user, việc sửa User::PERMITTED_ATTRS
tự nhiên sẽ làm ảnh hưởng đến cả index
mặc dù chúng không hề liên quan đến nhau.
Good:
Method chứa càng ít tham số đầu vào thì càng tốt. Tuy nhiên điều này không phải lúc nào cũng thực hiện được. Vì thế, trong trường hợp method có chứa nhiều tham số, hoặc có những tham số là optional, hãy sử dụng keyword arguments.
Bad:
Good:
Nếu method nhận tham số được truyền từ client và nó có thể là bất cứ giá trị nào, thì việc kiểm tra để tránh các ngoại lệ không mong muốn là cần thiết:
Good:
Tuy nhiên, với những tham số được truyền vào bởi chính lập trình viên thì việc kiểm tra là không cần thiết. Nếu có lỗi thì đó có thể được xem là lỗi typo và method cũng nên raise lỗi trong trường hợp này.
Bad:
Good:
Thông thường, chúng ta sẽ đọc code từ trên xuống dưới,
vì vậy methods cũng nên được đặt theo thứ tự này để dễ dàng folow hơn.
Bad:
Good:
Instance variables có thể được khởi tạo và sử dụng ở bất cứ đâu trong class. Vì vậy, nếu không được khai báo rõ ràng, sẽ rất khó để có thể theo dõi chúng khi chạy code:
Bad:
Khi đọc method save
chúng ta hoàn toàn không biết @user
được tạo ra ở đâu và khi nào điều này làm cho đoạn code trở nên không rõ ràng.
Good:
Vừa rồi là một số tips viết code Ruby tốt hơn. Hi vọng bài viết sẽ hữu ích với bạn.