10 Tips for Writing Cleaner & Better Code

Clean code - mã sạch là gì? Tại sao developer chúng ta cần mã sạch, nó liên quan gì đến chuyện trở thành một developer tốt hơn? Dưới đây là những chia sẽ về clean code của những con người đầu ngành trong nghiệp lập trình này.

Clean code does one thing well. (Bjarne Stroustrup)

Clean code is simple and direct, clean code read like well-written prose. (Grady Booch)

Clean code can be read, clean code should be literate. It has meaningful names (Dave Thomas)

Clean code always looks like it was written by someone who cares. (Micheal Feathers)

Reduced duplication, high expressiveness, and early building of simple abstractions. (Ron Jeffries)

You know you are working on clean code when each routine you reads turns out to be pretty much what you expected. (Ward Cunningham)

Những lợi ích từ clean code:

• Các vấn đề trở nên dễ dàng hơn để giải quyết: khi bắt đầu suy nghĩ về clean code, cách tiếp cận của bạn đối với việc giải quyết vấn đề thay đổi. Thuật toán và thiết kế phần mềm trở nên dễ hiểu.
• Không mất nhiều thời gian để bảo trì: clean code sẽ làm cho source code dễ đọc và dễ hiểu hơn, vì vậy bạn dành ít thời gian hơn để tìm ra những phân đoạn nhất định thực sự làm và có nhiều thời gian hơn để sửa chữa, sửa đổi, mở rộng, v.v.
• Các ý tưởng được truyền đạt rõ ràng hơn: nếu đang làm việc với các lập trình viên khác, clean code làm giảm khả năng hiểu lầm giữa tất cả các bạn, điều này cũng có nghĩa là ít lỗi hơn về lâu về dài.

Vậy làm thế nào để viết Code sạch? Viết Code sạch là một nghệ thuật, đơn giản bạn có thể nhìn vào và nhận biết đâu là Code sạch, đâu là Code bẩn, nhưng không có nghĩa là chúng ta biết làm thế nào để viết Code sạch. Sau đây, chúng ta sẽ cùng nhau tìm hiểu về cách bạn có thể bắt đầu viết clean code.

1. Use Descriptive Names

Các biến, các lớp và các hàm là gì? Có rất nhiều cách để trả lời, nhưng khi bạn thực sự nghĩ về nó, những điều đó không có gì hơn là interface giữa một lập trình và logic cơ bản của một ứng dụng. Khi bạn sử dụng tên không rõ ràng và không mô tả cho các biến, các lớp và các hàm, bạn thực sự đang làm logic ứng dụng trở nên khó hiểu cho bất kỳ lập trình viên nào đọc mã, kể cả bản thân mình.

“I’m not a great programmer; I’m just a good programmer with great habits.” — Kent Beck

Vì vậy, đặt tên biến là một nghệ thuật trong lập trình, đặt cái tên sao cho phải thật là ý nghĩa, dể hiễu, đọc phát hiểu luôn, ngay cả khi vài tháng trời mới mò lại đống code cũ mình từng viết thì bạn cũng có thể đọc hiểu ngay được.

Thí dụ như: biến có tên dxy có nghĩa là gì? Ai mà biết. Thậm chí đôi khi để hiểu được ý nghĩa của biến lại phải đọc toàn bộ đoạn mã. Mặt khác, ý nghĩa của một biến như distanceBetweenXY ngay lập tức được nhận ra. Điều này cũng đúng với việc đặt tên cho class hay function.

2. Give Each Class/Function One Purpose

Khi lập trình chắc chắn không thể tránh khỏi những lúc bạn phải đọc một hàm dài chứa cả trăm dòng code, khi mà nhìn tên hàm cũng không đoán nổi chức năng của nó. Hẳn là lúc đó, bạn sẽ sôi tiết lên và muốn chửi ngay cái thằng nào viết cái đoạn code thối như lày (lol).

“Programming is breaking one big impossible task into several small possible tasks.” — Jazzwant

Chính vì lẽ đó, Clean code là cứu tinh để khắc phục và cải thiện việc dễ dàng hiểu code của nhau(đặc biệt khi làm trong những dự án maintain). Clean code được chia thành các khối nguyên tử. Mỗi chức năng chỉ nên nhằm mục đích và để làm một điều duy nhất. Mỗi class cũng vậy, chỉ nên nhằm mục đích để đại diện cho một khái niệm cụ thể. Đây là một sự đơn giản hóa tất nhiên.

3. Delete Unnecessary Code

“Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?” — Alan J. Perlis

Thói quen xấu này là một trong những điều mà lập trình viên nào cũng từng trải qua và đôi khi vẫn còn phải vật lộn với thời gian. Nó thường xảy ra khi muốn sửa chữa hoặc tối ưu hóa một đoạn code, nhưng sau khi comments và viết lại đoạn code mới - và mặc dù nó hoạt động, thì vẫn giữ lại mã cũ ở đó.

Théo thời gian những comments đấy không cần thiết nữa và làm lộn xộn file nguồn. Do đó, khi có một đoạn code thừa, có cũng như không thì chúng ta cần loại bỏ khỏi source code.

4. Readability > Cleverness

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” — Brian W. Kernighan

Có quá nhiều lập trình viên kết hợp mã sạch - clean code với mã thông minh - clever code như thể nén mười dòng vào một thì trông nó sẽ clean hơn. Chắc chắn, nó chiếm không gian ít hơn trên màn hình, nhưng nó có thực sự dễ hiểu hơn? Đôi khi, có thể clean hơn nhưng hầu hết thời gian thì không phải như vậy.

Các lập trình yêu thích clever code bởi vì nó làm họ cảm thấy như mình vừa giải quyết câu đố hóc búa. Họ đã tìm ra một cách đặc biệt và độc đáo để thực hiện điều đó và nó hầu như đóng vai trò xác nhận các kỹ năng của lập trình viên. Nhưng để viết code sạch, bạn cần leave your ego at the door =))

Vậy nên, luôn luôn tối ưu hóa mã cho người tiếp theo, những người sẽ đọc nó, bởi vì có thể người tiếp theo thực sự là BẠN và không có gì đáng xấu hổ hơn là không thể đọc hoặc hiểu được sự thông minh của chính mình.

5. Keep a Consistent Coding Style

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. — Tim Peters, The Zen of Python

6. Choose the Right Architecture

“Without requirements and design, programming is the art of adding bugs to an empty text file.” — Louis Srygley

Có rất nhiều mô hình và kiến trúc khác nhau mà bạn có thể sử dụng để tạo dự án của mình. Nhưng hãy luôn lưu ý rằng, chọn đúng đối tượng cho nhu cầu của bạn, chứ không phải về chọn một trong những điều tốt nhất vì không có "tốt nhất" ở đây.

*Ví dụ: *

• Mô hình Model-View-Controller (MVC) rất phổ biến rong phát triển web hiện nay vì nó giúp giữ mã của bạn được tổ chức và thiết kế sao cho giảm tối đa các nỗ lực bảo trì.
• Tương tự, mô hình Entity-Component-System (ECS) rất phổ biến trong phát triển trò chơi bởi vì nó giúp mô đun dữ liệu trò chơi và logic theo cách làm cho việc bảo trì dễ dàng hơn, tất cả trong khi tạo ra mã dễ đọc hơn.

7. Master the Language’s Idioms

“A language that doesn’t affect the way you think about programming is not worth knowing.” — Alan J. Perlis

Một trong những khó khăn trong việc thạo một ngôn ngữ lập trình mới là học các sắc thái tách nó ra khỏi tất cả các ngôn ngữ khác. Những sắc thái này có thể là sự khác biệt giữa mã xấu, phức tạp và mã đẹp, dễ bảo trì.

8. Study the Code of Masters

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler, Refactoring: Improving the Design of Existing Code

Nếu bạn muốn viết code sạch, điều tốt nhất bạn có thể làm là xem code sạch sẽ trông như thế nào và cố gắng hiểu tại sao nó là như vậy - và không có cách nào tốt hơn để làm điều này bằng cách nghiên cứu các file nguồn của industry masters.

9. Write Good Comments

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John Woods

Write good comments” is the oldest piece of advice in the world of programming. Thực tế, ngay khi những người mới được giới thiệu về comments, họ sẽ được khuyến khích nhiều hơn để comment càng nhiều càng tốt. Đây là một nguyên tắc nhỏ: comments tồn tại để giải thích tại sao một đoạn code tồn tại thay vì những gì mà đoạn code đó thực sự làm. Nếu mã được viết đủ sạch, nó nên được tự giải thích như những gì nó làm - comments nên làm sáng tỏ về ý định đằng sau những gì nó đã được viết.

10. Refactor, Refactor, Refactor

“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.” — Martin Fowler, Refactoring: Improving the Design of Existing Code

Tóm tại, refactor chỉ là một thuật ngữ kỳ diệu để làm sạch mã mà không ảnh hưởng đến chức năng thực tế của nó.

Ví dụ ta có đoạn code sau:

box1.x = 10;

box1.y = 20;

box2.x = 30;

box2.y = 20;

box3.x = 50;

box3.y = 20;

box4.x = 70;

box4.y = 20;

Và đây là một cách tiếp cận để làm đẹp đoạn code trên hơn:

boxArray = [box1, box2, box3, box4];

for(int i = 0; i < sizeOf(boxArray); i++)
{
  boxArray[i].x = 10 + i * 20;
  boxArray[i].y = 20;
}

Bằng việc refactor ta có thể giải quyết những đoạn code có if lồng hay dry code và làm cho code trở nên trong sáng, dễ đọc cũng như dễ hiểu hơn rất nhiều.

Thanks for reading!

Bài viết được dịch từ đây