25 dòng code cho mỗi hàm có quá ngắn?

Rule 80/25 đó. Thi vô Google,MS, Apple, Symantec…code ko đc thế này là teo ngay đó

Em thấy code kernel có nhiều hàm hơn 25 dòng lắm anh ơi. Ví dụ như hàm đầu tiên của kernel start_kernel cũng 186 dòng tính cả blank line + comments. Bỏ hết blank line + comments đi chắc giảm được nhiều nhưng chắc chắn là hơn 25 dòng rồi.

torvalds/linux/blob/master/init/main.c#L502-L688

#ifdef TRACEPOINTS_ENABLED
static void __init initcall_debug_enable(void);
#else
static inline void initcall_debug_enable(void)
{
}
#endif


/*
* Set up kernel memory allocators
*/
static void __init mm_init(void)
{
	/*
	 * page_ext requires contiguous pages,
	 * bigger than MAX_ORDER unless SPARSEMEM.
	 */
	page_ext_init_flatmem();
	mem_init();
	kmem_cache_init();

Theo “Code Complete 2nd” thì cỡ 200 dòng đổ lại là được.

Where does all this leave the question of routine length in object-oriented programs? A large percentage of routines in object-oriented programs will be accessor routines, which will be very short. From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100– 200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as the routine’s cohesion, depth of nesting, number of variables, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. That said, if you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code.

McConnell, Steve (2004-06-09). Code Complete (2nd Edition) (Developer Best Practices) (Kindle Locations 4487-4495). Pearson Education. Kindle Edition.

From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100– 200 lines.

Đọc kĩ nhé. complex algorithm.

Yeah, đúng rồi anh. Nhưng một hàm có thể trở nên phức tạp. Vì thế 25 dòng là quá ngắn, như anh nói ở trên

Vẫn theo quy tắc cũ 80 cột / 25 hàng tối đa cho một hàm.

P/S: Thực ra hàm start_kernel cũng không phải là thuật toán phức tạp, chỉ có điều là khởi tạo nhiều thứ quá. Hầu hết các hàm này đều là init.

Chưa thấy xác nhận là hàm start_kernel là hàm đang được code tốt. Về bản chất hàm này có thể tách ra được nữa.

Ghi chú thêm: hàm này sử dụng Template Method Design Pattern.

Những gì đã là nguyên lý cơ bản hay Good/Best Practices thì cứ cố gắng theo vậy mà làm. Càng gần tới thì càng tốt chứ không phải là dập khuôn.

1. Code phải rõ ràng dễ hiểu.
2. Code phải hiểu được, nghĩa là phải test được (Unit Test, Function Test)
3. Code đảm bảo module hoá càng tối ưu càng tốt. (Strong Cohesion, Loose Coupling)
4. Nói riêng về code một hàm, gói gọn thế nào sao cho, nhìn đúng một màn hình có thể thấy được cả hàm đó. Màn hình ngày xưa là 80/25 nên chính là lí do tại sao code tốt phải gói gọn trong 80/25. Nếu không nhầm thì ngày xưa đọc cuốn Clean Code và Pramatic Programmer thì có nói là, code đi code lại, refactor đi, refactor liên tục, sẽ tới một giới hạn là code clean trong giới hạn 80/25. (cái này nhớ là thế, sai chỗ nào thì các bạn sửa giùm).

80 cột 25 hàng bằng với kích thước của màn hình console (khi thu nhỏ)

cái này màn hình khi code Pascal chăng?
e vừa test:

Pasted image1366x768 718 KB

25 dòng, 80 số / dòng.

Đây là một quy tắc cũ, nhưng rất chất lượng đấy Làm theo đi sẽ thấy code của mình tốt hơn nhiều.

@laptrinhio Đồng ý với anh. Theo em đọc trong Code Complete thì hàm init là một ngoại lệ. Trước đây em không biết luật 25 dòng, nhưng em thông thường code cũng trong vòng 25 dòng thôi.

25 dòng ở đây là không tính comments, blank line.

Theo mình nhớ đây là chuẩn của IBM về coding style ngày trước. Còn bây giờ thì có nhiều chuẩn mới rồi tùy ngôn ngữ. Cái này thì các IDE cũng đều hỗ trợ để người dùng dễ nhìn(dòng kẻ đỏ dọc) thấy mình đang làm đúng hay sai. Nó giúp người viết phải phân tách các requirements ra thành các business riêng biệt nhằm dễ dàng cho việc dùng lại cũng như thực hiện unit test các functions. Nói chung làm theo được là tốt nhất.

25 dòng là dài. Thầy mình dạy, trong lập trình có quy tắc DON’T REPEAT YOURSELF, và mỗi hàm tối đa nên 10 dòng. Ban đầu cũng cảm thấy lạ, nhưng khi thầy đưa một số mã nguồn mà thầy viết thì khá bất ngờ, code rất đẹp và đúng là ko có hàm nào quá 10 dòng.

10 dòng thì khắc khe quá không nhỉ

Nên chứ không phải tối đa, không thể khuôn phép trong 25 dòng, từ thuộc vào từng hàm và tính chi tiết của hàm đó

Bạn có thế nói thêm về qui tắc đó không? minh search đọc ko hiểu cho lắm

Nghe tới 25 dòng có lẽ là ngắn, nhưng thực ra nếu kiểm tra lại code của chính mình, các bạn sẽ thấy hầu hết các hàm của mình rất ngắn.

P/S: Đấy là đối với người đã đi làm hoặc là code nhiều rồi nhé

Đơn giản chỉ là code mỗi hàm <= 10 dòng. Chỉ cần có sự xuất hiện >= 2 đoạn code ngắn tương tự nhau thì cho nó vào 1 hàm mới
@ltd Dạ, e chỉ được dạy như vậy thôi, ban đầu e cũng thấy khó để làm như vậy. Nhưng nhìn code của thầy thì có vẻ là hợp lí. Nhưng hiện tại e chưa làm được điều đó, nhiều đoạn code nếu tách ra quá ngắn cũng rắc rối mà khó sửa

Chỉ cần có sự xuất hiện >= 2 đoạn code ngắn tương tự nhau thì cho nó vào 1 hàm mới

Nên tách theo “logic” của việc tính toán chứ không nên tách để nó “ngắn” hơn. Ví dụ 3-4 dòng code làm một nhiệm vụ riêng thì có thể tách ra làm một hàm. Không cần thiết code đó lặp lại hoặc ngắn tương tự nhau.

Nếu em có vấn đề về việc tách hàm, khi nào nên tách thì em có thể tạo topic để thảo luận có nên tách không? Nếu có, tách như thế nào?

Vậy hàm có nhiều chức năng thì sao ?
Mình có xem nhiều mã (được viết bởi cá dev chuyên nghiệp cũng không thấy theo quy tắc này

Vậy hàm có nhiều chức năng thì sao ?

Thì tách ra thành nhiều hàm con để giải quyết.

Mình có xem nhiều mã (được viết bởi cá dev chuyên nghiệp cũng không thấy theo quy tắc nà

Chắc là chưa đủ chuyên nghiệp rồi. Hì, đùa thôi chứ mình thấy nhiều code dài lắm, rất khó đọc, khó hiểu, khó fix bug dễ tạo bugs. Ví dụ có những hàm lên 1000+ dòng đọc cực kỳ đau mắt.

Have you written very long functions? If so, why?

Have you written very long functions? If so, why?

Bên em tiêu chuẩn 1 funtion tối đa là 1 trang giấy A4. Có lúc ngươi ta in code ra giấy để review.