Subscribe:

Thứ Sáu, 14 tháng 8, 2015

Clean Code - Chapter 10: Classes

Chapter 10: Classes

Class Organization (Tổ chức của Class)

Theo quy ước, Class nên bắt đầu với một danh sách các biến (variables). Hằng số tĩnh công khai (public static constants) nếu có nên để đầu tiên. Sau đó đến các biến tĩnh riêng tư (private static variables). Hiếm khi có một lý do tốt để đặt biến công khai (public variable).

Public functions nên được thực hiện theo danh sách các biến. Đặt các tiện ích riêng tư được gọi bởi một public funcion đặt ngay sau public function đó. Điều này tuân theo quy tắc Stepdown và giúp chương trình được đọc như một bài báo.

Thứ Năm, 13 tháng 8, 2015

Clean Code - Chapter 7: Error Handling

Chapter 7: Error handling

Nghe có vẻ kỳ lạ khi nói về xử lý lỗi trong cuốn sách về clean code. Chỉ là xử lý lỗi là một trong những điều mà tất cả chúng ta phải làm khi chúng ta lập trình. Xử lý lỗi là quan trọng nhưng nếu nó che lấp đi logic thì nó là sai lầm.

Use Exceptions Rather Than Return Codes (Sử dụng ngoại lệ hơn là trả về Codes)

Bạn có thể thiết lập một error flag hoặc trả về một mã lỗi mà người gọi có thể kiểm tra.

public class DeviceController {
   ...
   public void sendShutDown() {
      DeviceHandle handle = getHandle(DEV1);

Clean Code - Chapter 5: Formatting

Chapter 5: Formatting

Khi mọi người nhìn vào, chúng tôi muốn Code nhìn vào được gọn gàng, nhất quán, chi tiết. Muốn mọi người cảm nhận được  đây là do một chuyên gia làm việc. Nếu thay vào đó họ thấy được một khối lượng code xáo trộn trông giống như được viết bởi một loạt thủy thủ say rượu, sau đó họ có thể kết luận rằng sự thiếu chú ý đến chi tiết tràn ngập trong mọi khía cạnh khác của dự án.

Thứ Tư, 12 tháng 8, 2015

Clean Code - Chapter 4: Comments

Chapter 4: Comments

"Đừng bình luận trên Code xấu - Hãy viết lại nó."
-Brian W.Kernighan và P.J.Plaugher-
Comment có thể giúp đỡ rất tốt nếu đặt đúng vị trí, nhưng nó cũng có thể trở nên tồi tệ, gây nhiễu loạn không tin khi đặt sai hay cung cấp thông tin không chính xác.

Clean Code - Chapter 3: Functions

Chapter 3: Functions


Trong những ngày đầu của lập trình, chúng ta biên soạn hệ thống của chúng ta bằng chương trình (routines - thủ tục, hàm, chương trình con) và những chương trình con (subroutines). Sau đó là thời đại của Fortran và PL/1 hệ thống của chúng ta bao gồm những chương trình (programs), chương trình con (subprograms), và chức năng (functions). Đến nay chỉ có chức năng là tồn tại được từ những ngày đầu tiên. Chức năng là đơn vị đầu tiên tổ chức nên bất cứ chương trình nào. Rất khó để hiểu một hàm chức năng dài với nhiều mức trừu tượng khác nhau, các lệnh if lồng nhau, các chuỗi xa lạ và những chức năng lẻ khác được gọi. Tuy nhiên, chỉ với một vài phương pháp rút gọn đơn giản, thay đổi một số tên, và tái cấu trúc lại một ít, là có thể nắm được đường cơ bản chính ở trong chức năng.

Thứ Ba, 11 tháng 8, 2015

Clean Code - Chapter 2: Meaningful Names

Chapter 2: Meaningful Names

Introduction


Name are everywhere!

Use Intention-Revealing Names (Sử dụng tên bộc lộ mục đích)

Có thể nói đơn giản là bộc lộ ý nghĩa qua tên gọi. Chọn một cái tên cần thời gian nhưng để nhớ nó còn tốn thời gian hơn nữa. Lưu tâm đến những cái tên bạn chọn và thay đổi chúng nếu bạn tìm thấy một thay thế tốt hơn.

Tên là câu trả lời cho một câu hỏi lớn. Nó sẽ nói cho bạn biết tại sao nó tồn tại, nó dùng để làm gì, và nó sử dụng ra sao.

Thứ Hai, 10 tháng 8, 2015

Clean Code - Chapter 1: Clean Code

Chapter 1: Clean Code


Trước hết, bạn đọc cuốn sách này bởi hai lý do:
Đầu tiên, bạn là một lập trình viên.
Thứ hai, bạn muốn trở thành một lập trình viên tốt.

There Will Be Code

Người ta có thể cho rằng bằng cách nào đó về sau viết code sẽ không còn là vấn đề nữa; rằng chúng ta chỉ cần quan tâm đến các Mô hình và các Yêu cầu là đủ. Thực tế một số người cho rằng thời đại của chúng ta đang tiến gần tới sự kết thúc của việc viết Code. Lập trình viên sẽ không cần thiết nữa bởi vì những khách hàng kinh doanh sẽ tự tạo ra các chương trình bằng cách nhập các thông số kỹ thuật.

Điều đó là phi lý! Chúng ta sẽ không bao giờ thoát ra khỏi các đoạn code, bởi vì code đại diện cho chi tiết của các yêu cầu. Chi tiết ở một vài mức độ không thể bỏ qua hay trừng tượng hóa được mà