Loại bỏ các con số ma thuật: Khi nào nên nói là No No?

Tất cả chúng ta đều biết rằng các số ma thuật (giá trị được mã hóa cứng) có thể tàn phá chương trình của bạn, đặc biệt là khi đến lúc sửa đổi một phần mã không có nhận xét, nhưng bạn vẽ đường này ở đâu?

Chẳng hạn, nếu bạn có một hàm tính số giây giữa hai ngày, bạn có thay thế không

seconds = num_days * 24 * 60 * 60

với

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

Tại thời điểm nào bạn quyết định rằng nó hoàn toàn rõ ràng giá trị mã hóa cứng có nghĩa là gì và để nó một mình?

Có hai lý do để sử dụng hằng số tượng trưng thay vì chữ số:

1. Để đơn giản hóa bảo trì nếu số ma thuật thay đổi. Điều này không áp dụng cho ví dụ của bạn. Điều cực kỳ khó xảy ra là số giây trong một giờ hoặc số giờ trong một ngày sẽ thay đổi.

2. Để cải thiện khả năng đọc. Biểu thức "24 * 60 * 60" là khá rõ ràng đối với hầu hết mọi người. "SECONDS_PER_DAY" cũng vậy, nhưng nếu bạn đang tìm kiếm một lỗi, bạn có thể phải kiểm tra xem SECONDS_PER_DAY đã được xác định chính xác chưa. Có giá trị trong sự ngắn gọn.

Đối với các số ma thuật xuất hiện chính xác một lần và độc lập với phần còn lại của chương trình, việc quyết định có tạo biểu tượng cho số đó hay không là vấn đề của hương vị. Nếu có bất kỳ nghi ngờ nào, hãy tiếp tục và tạo một biểu tượng.

Đừng làm điều này:

public static final int THREE = 3;

Tôi sẽ giữ quy tắc không bao giờ có số ma thuật.

Trong khi

seconds = num_days * 24 * 60 * 60

Hoàn toàn có thể đọc được hầu hết thời gian, sau khi đã mã hóa 10 giờ mỗi ngày trong ba hoặc bốn tuần ở chế độ giòn

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

dễ đọc hơn nhiều

FrustratedWithFormsDesigner là tốt hơn:

seconds = num_days * DAYS_TO_SECOND_FACTOR

hoặc thậm chí tốt hơn

seconds = CONVERT_DAYS_TO_SECONDS(num_days)

Mọi thứ sẽ ngừng rõ ràng khi bạn rất mệt mỏi. Mã phòng thủ .

Thời gian để nói không là gần như luôn luôn. Thời gian mà tôi thấy dễ dàng hơn khi chỉ sử dụng các số được mã hóa cứng ở những nơi như bố cục UI - tạo ra một hằng số cho việc định vị mọi điều khiển trên biểu mẫu sẽ rất lập phương và mệt mỏi và nếu mã đó thường được xử lý bởi nhà thiết kế UI không quan trọng lắm ... Trừ khi giao diện người dùng được đặt ra một cách linh hoạt hoặc sử dụng các vị trí tương đối cho một số neo hoặc được viết bằng tay. Trong trường hợp đó, tôi muốn nói rằng tốt hơn là xác định một số hằng có ý nghĩa cho bố cục. Và nếu bạn cần một yếu tố mờ nhạt ở đây hoặc ở đó để căn chỉnh / định vị một cái gì đó "vừa phải", thì điều đó cũng nên được xác định.

Nhưng trong ví dụ của bạn, tôi nghĩ rằng thay thế 24 * 60 * 60bằng DAYS_TO_SECONDS_FACTORlà tốt hơn.

Tôi thừa nhận rằng các giá trị được mã hóa cứng cũng ổn khi bối cảnh và cách sử dụng hoàn toàn rõ ràng. Tuy nhiên, đây là một cuộc gọi phán xét ...

Thí dụ:

Như @rmx đã chỉ ra, sử dụng 0 hoặc 1 để kiểm tra xem danh sách có trống không, hoặc có thể trong giới hạn của vòng lặp là một ví dụ về trường hợp mục đích của hằng số rất rõ ràng.

Dừng lại khi bạn không thể xác định ý nghĩa hoặc mục đích của số.

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

dễ đọc hơn nhiều so với việc chỉ sử dụng các con số. (Mặc dù có thể dễ đọc hơn bằng cách có một SECONDS_PER_DAYhằng số duy nhất , nhưng đó là một vấn đề hoàn toàn riêng biệt.)

Giả sử rằng một nhà phát triển nhìn vào mã có thể thấy những gì nó làm. Nhưng đừng cho rằng họ cũng biết tại sao. Nếu liên tục của bạn giúp hiểu lý do tại sao, đi cho nó. Nếu không, đừng.

Nếu bạn kết thúc với quá nhiều hằng số, như được đề xuất bởi một câu trả lời, hãy xem xét sử dụng tệp cấu hình bên ngoài, vì có hàng tá hằng số trong một tệp không cải thiện chính xác khả năng đọc.

Có lẽ tôi sẽ nói "không" với những thứ như:

#define HTML_END_TAG "</html>"

Và chắc chắn sẽ nói "không" với:

#define QUADRATIC_DISCRIMINANT_COEF 4
#define QUADRATIC_DENOMINATOR_COEF  2

Một trong những ví dụ tốt nhất mà tôi đã tìm thấy để thúc đẩy việc sử dụng hằng số cho điều hiển nhiên như HOURS_PER_DAYlà:

Chúng tôi đã tính toán thời gian ngồi trong hàng đợi công việc của một người. Các yêu cầu được xác định một cách lỏng lẻo và lập trình viên khó mã hóa 24ở một số nơi. Cuối cùng, chúng tôi nhận ra rằng thật không công bằng khi trừng phạt người dùng vì đã ngồi trên một vấn đề trong 24 giờ khi thực sự chỉ hoạt động trong 8 giờ một ngày. Khi tác vụ đến để khắc phục điều này VÀ xem những báo cáo nào khác có thể có cùng một vấn đề, rất khó để grep / tìm kiếm thông qua mã cho 24 sẽ dễ dàng hơn nhiều để grep / tìm kiếmHOURS_PER_DAY

Tôi nghĩ rằng miễn là con số hoàn toàn không đổi và không có khả năng thay đổi, điều đó hoàn toàn chấp nhận được. Vì vậy, trong trường hợp của bạn, seconds = num_days * 24 * 60 * 60sẽ ổn thôi (tất nhiên là giả sử rằng bạn không làm điều gì đó ngớ ngẩn như thực hiện phép tính này trong một vòng lặp) và tốt hơn là dễ đọc hơn seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE.

Đó là khi bạn làm những việc như thế này thật tệ:

lineOffset += 24; // 24 lines to a page

Ngay cả khi bạn không thể phù hợp với các dòng nữa trên trang hoặc ngay cả khi bạn không có ý định thay đổi nó, thay vào đó hãy sử dụng một biến liên tục, bởi vì một ngày nào đó nó sẽ quay trở lại ám ảnh bạn. Cuối cùng, vấn đề là khả năng đọc, không lưu 2 chu kỳ tính toán trên CPU. Đây không còn là năm 1978 khi các byte quý giá đã bị ép cho tất cả giá trị của chúng.

seconds = num_days * 24 * 60 * 60

Là hoàn toàn tốt. Đây không phải là những con số thực sự kỳ diệu vì chúng sẽ không bao giờ thay đổi.

Bất kỳ số nào có thể thay đổi hợp lý hoặc không có ý nghĩa rõ ràng nên được đưa vào các biến. Có nghĩa là khá nhiều tất cả trong số họ.

Tôi sẽ tránh tạo các hằng số (giá trị ma thuật) để chuyển đổi một giá trị từ đơn vị này sang đơn vị khác. Trong trường hợp chuyển đổi tôi thích một tên phương thức nói. Trong ví dụ này, đây sẽ là ví dụ DayToSeconds(num_days)bên trong phương thức không cần các giá trị ma thuật bởi vì, ý nghĩa của "24" và "60" là rõ ràng.

Trong trường hợp này, tôi không bao giờ sử dụng giây / phút / giờ. Tôi sẽ chỉ sử dụng TimeSpan / DateTime.

Sử dụng bối cảnh làm tham số để quyết định

Ví dụ: bạn có một hàm gọi là "notifySecondsB between: aDay và: AnotherDay", bạn sẽ không cần phải thực hiện nhiều biểu hiện về những gì các số đó làm, vì tên hàm khá đại diện.

Và một câu hỏi khác là, những khả năng để tính toán nó theo một cách khác? Đôi khi có rất nhiều cách để làm điều tương tự, vì vậy để hướng dẫn các lập trình viên trong tương lai và chỉ cho họ phương pháp bạn đã sử dụng, việc xác định các hằng số có thể giúp tìm ra nó.