Làm thế nào là quan trọng để giảm số lượng dòng trong mã?

Tôi là một nhà phát triển phần mềm làm việc trên J2SE (java lõi).
Thông thường trong quá trình đánh giá mã của chúng tôi, chúng tôi được yêu cầu giảm số lượng dòng trong mã của chúng tôi.

Không phải là loại bỏ mã thừa, mà là theo một phong cách tập trung vào làm những việc tương tự với ít dòng hơn trong mã, trong khi tôi tin rằng có sự rõ ràng trong mã ngay cả khi điều đó có nghĩa là tăng số lượng dòng.

Bạn nghĩ gì là cách làm đúng?
Nếu LỘC (dòng mã) là một số nhỏ, thì nó ảnh hưởng đến mã như thế nào? Nếu LỘC là một số lớn hơn, nó ảnh hưởng đến mã như thế nào?

ví dụ từ trang web: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

Vấn đề với các phép đo, cho dù chúng có ý định tốt đến đâu, chính là hành động đo vật phẩm làm cho nó trở nên quan trọng, và hệ quả, hành động không đo lường một vật phẩm khiến nó không quan trọng. Nó là hoàn toàn cần thiết để đo lường những gì quan trọng, và không đo lường những gì không quan trọng.

Đo SLOC (Đó là hiệu quả những gì đánh giá của bạn đang làm), làm cho SLOC trở nên quan trọng .... SLOC có quan trọng không? - hoàn toàn không, chưa bao giờ (Các cuộc thi lập trình bên ngoài ), sẽ không bao giờ có trong một tổ chức thương mại.

Hãy tự hỏi mình một câu hỏi đơn giản - làm thế nào để "Giảm SLOC của thói quen này" làm cho mã của mọi người trở nên tốt hơn. Điều có lẽ xảy ra trong trường hợp này là SLOC đang được sử dụng như một cách ngây thơ để đo lường sự phức tạp. Những gì bạn phải tránh bằng mọi giá là đếm những hạt đậu dễ ​​đếm - các biện pháp khách quan như SLOC, thay vì đếm những thứ quan trọng, nhưng khó đếm - ví dụ: Độ dễ đọc, độ phức tạp, v.v.

Tôi đồng ý với người đánh giá mã của bạn, nhưng với dấu hoa thị. Mỗi tuyên bố mà bạn viết trong mã của mình là một trách nhiệm kỹ thuật - đó là một điểm thất bại tiềm năng. Nếu bạn viết một phương thức với 10 câu lệnh và đồng nghiệp của bạn viết một phương thức đạt được chức năng tương tự với 5 câu lệnh, thì khả năng của anh ta sẽ 'tốt hơn' khi được đo bằng khả năng của các vấn đề (có nhiều lần mã của bạn có thể sai gấp đôi phức tạp, hoặc có vấn đề).

Đây là dấu hoa thị, mặc dù. Đây không phải là về số lượng dòng mã thực tế trong ý tưởng bởi vì bạn có thể giảm số lượng dòng bằng một cái gì đó như:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

Đây là một dòng mã, nhưng nó là một nơi mà một số lượng đáng kinh ngạc có thể sai. Vì vậy, tôi muốn tập trung vào việc làm nhiều nhất với ít câu lệnh nhất - viết càng nhiều mã càng tốt để bạn hoàn thành công việc và không làm gì nữa. Ít nhất, tôi nghĩ đó là những gì người đánh giá mã của bạn đang lái xe.

Cá nhân, tôi nghĩ rằng có một sự cân bằng để được đánh. Như tôi đã nói, mỗi câu lệnh bạn viết là một trách nhiệm pháp lý, nhưng nếu rút ra một biến cục bộ có tên mô tả làm cho phương thức của bạn rõ ràng hơn và dễ đọc hơn, thì cũng có trường hợp được thực hiện cho điều đó. Tôi nghĩ bạn có thể dễ dàng rơi vào tình huống mọi người ngụy biện cho những khác biệt thẩm mỹ tương đối nhỏ, nhưng về tổng thể, tôi nghĩ những người đánh giá của bạn có ý tưởng đúng - ủng hộ giảm thiểu số lượng những điều có thể sai.

Theo lời khuyên của người đánh giá theo nghĩa đen sẽ không làm được gì, bởi vì kết quả trực tiếp rõ ràng là thúc đẩy một lớp lót ngắn (giới hạn độ dài dòng mặc dù). Tôi tin rằng bài học được học ở đây, mặc dù, là làm cho mã của bạn làm ít việc hơn .

Nói cách khác, đây là một lời kêu gọi cho sự đơn giản. Một tuyên bố khá phổ biến rằng mã là một trách nhiệm pháp lý, không phải tài sản , vì vậy giảm số tiền của nó trong khi bảo tồn chức năng là một nỗ lực cao quý. Điều này có thể đạt được bằng cách tiếp cận trực tiếp, thực tế hơn, giải quyết vấn đề trực tiếp và ưu tiên các giải pháp ngắn gọn.

Giống như Ken Thompson từng nói: Một trong những ngày làm việc hiệu quả nhất của tôi là vứt bỏ 1000 dòng mã .

Tôi có xu hướng đồng ý với quan điểm của bạn là "có sự rõ ràng trong mã ngay cả khi điều đó có nghĩa là tăng số lượng dòng."

Tôi đã thấy quá nhiều lớp lót khá ngắn gọn, nhưng nó không rõ ràng ngay lập tức những gì họ đang làm. Khả năng đọc là vua vì các nhà phát triển khác sẽ phải duy trì mã của bạn.

Tôi sẽ lập luận rằng một điều tốt hơn để nhắm đến là các phương pháp ngắn. Không ngắn vì lợi ích của một vài dòng mã, nhưng ngắn vì chúng làm một việc duy nhất.

Tôi hiện đang làm việc như một nhà phát triển ứng dụng cao cấp và nhà phân tích kinh doanh dự án cho một công ty lớn và không bao giờ có số lượng phát triển của tôi là một trung tâm quan tâm. Tuy nhiên, tôi tin rằng mã càng cô đặc thì càng tốt, NHƯNG không phải là chi phí để có thể nhanh chóng phân tích và sửa chữa (hoặc thêm vào) nó. Đối với tôi, khi bạn phụ trách ứng dụng kinh doanh quan trọng rằng PHẢI có mức độ mở rộng lớn và có khả năng thay đổi nhanh chóng trong một môi trường thay đổi không ngừng, mã ngắn gọn, dễ đọc là một trong những yếu tố quan trọng nhất trong phát triển . Đối với tín dụng trả lời của Erik Dietrich , điều này:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

sẽ hoàn toàn không thể chấp nhận được đối với tôi, tuy nhiên, tôi thấy việc thay đổi tất cả các mã công ty hiện có từ:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

đến:

value.prop =  boolean ? option1 : option2;

là một lựa chọn cô đọng mã tuyệt vời mà không hy sinh khả năng đọc.

Theo như cách nó ảnh hưởng đến mã? Tôi chưa bao giờ nhận thấy hiệu suất tăng hoặc giảm từ, giả sử, 100 dòng mã. Thực tế đơn giản là đó là quá trình bạn sử dụng để đến sản phẩm cuối cùng nhiều hơn số lượng dây chuyền cần đến đó. Tôi đã thấy một số quy trình được viết rất cô đọng, tuy nhiên không hiệu quả, thực hiện khác với các mã dài hơn với dòng mã tốt hơn.

IMO, đó là một ý tưởng tồi để đo lường hiệu quả mã bằng số LỘC tầm thường. Có nhiều hơn những gì làm cho mã được thiết kế đúng và hiệu quả.

Theo kinh nghiệm của tôi, mã hiệu quả:

• không phá vỡ bất kỳ nguyên tắc RẮN
• có thể đọc và tự giải thích
• vượt qua bài kiểm tra về sự đơn giản của Albert Einstein: "Mọi thứ nên được làm đơn giản nhất có thể, nhưng không đơn giản hơn."

Có rất nhiều câu trả lời ở đây giải quyết những ưu và nhược điểm kỹ thuật của việc giữ LỘC và liệu đó có phải là một thước đo phần mềm chất lượng có ý nghĩa hay không. Đó không phải là câu hỏi này. Những gì nó nói là làm thế nào để đối phó với quản lý mà khăng khăng tuân thủ giáo điều ngây thơ với một quy tắc mã hóa cụ thể.

Đáng buồn thay, mọi người thường nắm bắt được những điều là lời khuyên tốt khi được sử dụng trong bối cảnh thích hợp và áp dụng thực tế, đưa họ ra khỏi bối cảnh đó và áp dụng chúng một cách giáo điều trong khi không đánh giá cao những vấn đề mà lời khuyên tồn tại để giảm thiểu ngay từ đầu .

Mục đích của lời khuyên liên quan đến việc giữ LỘC là để tránh việc tạo ra các phương pháp cố gắng làm quá nhiều trong một lần và không khuyến khích việc tạo ra "các lớp thần", vốn biết quá nhiều về các khía cạnh của một thiết kế không phải là của họ trách nhiệm trực tiếp và tất cả các lớp khác trong hệ thống phụ thuộc vào. Một ưu điểm khác của mã ngắn hơn là nó dễ đọc hơn, mặc dù như bạn đã chỉ ra, bạn có thể lạm dụng nó đến mức mà khả năng đọc thực sự bắt đầu bị ảnh hưởng.

Có những lợi thế rõ ràng đối với số lượng LỘC thấp (các phương pháp nhỏ phù hợp với đầu của bạn dễ dàng hơn so với số lượng lớn, ít mã hơn có nghĩa là ít sai sót hơn, v.v.), nhưng nó cũng tuân theo luật giảm lợi nhuận. Tái cấu trúc một phương thức 150 dòng thành một số 20 phương thức dòng là một chiến thắng lớn hơn nhiều so với tái cấu trúc một phương thức 10 dòng thành một phương thức 7 dòng.

Khi việc tái cấu trúc như vậy phải trả giá bằng một số khía cạnh khác của thiết kế phần mềm tốt (chẳng hạn như khả năng đọc) thì bạn đã đạt đến điểm mà bạn có thể biện minh là không làm việc đó. Loại bỏ các biến cung cấp ngữ cảnh cho ý nghĩa của mã và thay thế chúng bằng chữ không phải là một điều rất xấu phải làm. Mã tốt hầu như không có nghĩa đen trong đó. Tuy nhiên, các biến này (và các hằng số được đặt tên) là các dòng mã không trực tiếp đóng góp cho chương trình và vì vậy nếu LỘC được tôn thờ như một loại thần thì các dòng làm rõ như vậy sẽ rất nguy hiểm khi được cắt tỉa để giành chiến thắng nhanh chóng và một số lời khen sai lầm từ quản lý.

Tôi tin rằng bạn đủ thông minh để nhận ra điều này, thực tế đó là lực đẩy của câu hỏi ban đầu của bạn. Vấn đề không phải là sự hiểu biết của bạn khi nào việc giảm mã là tốt và khi không, vấn đề là sự giáo điều trong việc áp dụng những gì thông thường là một thực hành hợp lý một cách bừa bãi.

Tôi khuyên bạn nên dành thời gian để trò chuyện với quản lý của mình, giải thích vị trí của bạn và lý do tại sao bạn cảm thấy rằng những gì bạn được yêu cầu làm hại mã hơn là giúp nó. Cố gắng tránh đối đầu, nhưng hãy cố gắng duy trì lý trí và bình tĩnh trong suốt cuộc thảo luận như vậy. Điều quan trọng là quản lý của bạn hiểu rằng lập trình là một hoạt động thực dụng và lời khuyên thực hành tốt nhất chỉ hữu ích nếu được áp dụng theo cách thực dụng. Thực hành tốt nhất được viết trong một cuốn sách, không được khắc trên đá và khi nó xung đột (mã ngắn so với mã có thể đọc được) thì tùy thuộc vào lập trình viên để áp dụng phán đoán của họ về cách thực hành tốt nhất. Hy vọng họ là những người hợp lý, đánh giá cao đầu vào như thế này.

Bạn cũng cần phải dũng cảm một chút, bởi vì nếu bạn đang bị áp lực phải giảm LỘC nơi bạn nghĩ rằng nó không cần thiết hoặc không phù hợp thì dù sao bạn cũng sẽ thay đổi vì cuộc sống bình lặng. Bạn cần chống lại việc này, và bạn phải "sở hữu" quyết định đó. Trong tình huống quản lý hợp lý, bạn không cần phải tuân thủ chính xác các nguyên tắc của họ, nhưng bạn sẽ có thể biện minh cho bất kỳ trường hợp nào bạn không làm.

Đáng buồn thay, mọi người có thể là không hợp lý, đặc biệt là khi nói đến những người thấp hơn trong trật tự mổ xẻ đặt câu hỏi về quyết định của họ và các quy tắc họ đã áp đặt cho bạn. Họ có thể chọn không hợp lý. Bạn cần phải chuẩn bị cho điều đó quá. Nếu bạn có thể chứng minh các trường hợp trong đó thực tiễn tốt nhất của LỘC xung đột trực tiếp với thực tiễn tốt nhất khác và tại sao điều đó làm tổn hại đến sản phẩm và nếu bạn có thể thực hiện điều đó trong các phần của cơ sở mã mà họ có ít hoặc không có sự tham gia của cá nhân (thì điều đó không xảy ra Có vẻ như một cuộc tấn công cá nhân vào công việc hoặc công việc mà họ giám sát) thì điều này có thể giúp củng cố lập luận của bạn. Một lần nữa, bạn phải chuẩn bị để biện minh cho bản thân một cách bình tĩnh, hợp lý và có thể "sở hữu" những lý lẽ bạn đang đưa ra.

Với điều kiện quản lý của bạn là những người hợp lý thì họ phải đánh giá cao những gì bạn nói có giá trị nếu bạn có thể cung cấp bằng chứng để hỗ trợ cho yêu cầu của mình.

Tôi nghĩ rằng bạn thực sự nên cố gắng để có chức năng với một số lượng nhỏ SLOC.

Nếu LỘC (dòng mã) là một số nhỏ, thì nó ảnh hưởng đến mã như thế nào và nếu LỘC là một số lớn hơn, thì nó ảnh hưởng đến mã như thế nào?

Lý tưởng nhất là nên hiểu sơ lược về 8 dòng mã hơn là hiểu 30.

Điều đó không có nghĩa là 30 LỘC được nén trong 8 dòng sẽ dễ hiểu hơn.

Bạn nghĩ gì là cách làm đúng.

Thông thường trong một hàm, tôi cố gắng nhóm nó theo các mức độ trừu tượng ("mã IO ở đây", "xác nhận ở đây", "tính toán ở đây", v.v.).

Sau đó, tôi chia nó thành các khối, cách nhau bởi một dòng trống. Nếu mã nhiều hơn khoảng mười dòng, tôi trích xuất mỗi khối thành một hàm khác nhau (dù sao tôi cũng làm vậy với mã xuất hiện nhiều lần). Tôi đã nghe một cuộc tranh luận về việc phá vỡ hiệu suất theo cách này (các cuộc gọi chức năng không cần thiết) nhưng trong thực tế, tôi chưa bao giờ gặp phải một tắc nghẽn về hiệu suất do việc này gây ra.

Điều đó nói rằng, tôi đã thực hiện các chức năng với việc trích xuất này và sau đó, chức năng này dài ~ 40 dòng (mã C). Nếu mã được nhóm càng nhiều càng tốt, tôi không thấy vấn đề với các hàm dài hơn.

Tôi nghĩ điều quan trọng là tập trung vào mã sạch, tài liệu tự động, hơn LỘC. Tuy nhiên, tôi không thực sự thích ví dụ của bạn, bởi vì nó giải thích những gì mã đang làm, mà không nói lý do tại sao. Ví dụ: cái này:

boolean sweet_sixteen = (tuổi == 16);

là khá dư thừa. Bất cứ ai đọc "tuổi == 16" đều biết điều đó. Tôi thà viết mã như thế này:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

Logic về việc quyết định khi nào sẽ ném bữa tiệc tách biệt với System.out, có thể được kiểm tra và thật dễ hiểu. Quan trọng hơn, mặc dù, ai đó đọc mã có thể hiểu lý do nó được viết theo cách đó ("công ty muốn tổ chức một bữa tiệc lớn cho một số người").

Tôi nghĩ rằng ít dòng mã hơn = mã dễ đọc hơn

Nhưng tất nhiên, có một số giới hạn, khi bạn bắt đầu thu nhỏ / che khuất mã của mình chỉ để nhận được ít dòng hơn.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

Đây là sự thu nhỏ logic vẫn giữ nguyên, chỉ là ít đọc hơn. Điều này không nên được thực hiện bởi con người, việc thu nhỏ này được thực hiện bằng máy để được đọc bằng máy.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Nếu bạn có thể loại bỏ một số đoạn mã và thuật toán vẫn đang làm những gì nó phải làm, ok hãy tiếp tục. Chỉ cần không thu nhỏ mã của bạn, có những công cụ tốt hơn để làm điều đó.

Tôi không nghĩ ít dòng mã hơn == mã dễ đọc hơn. Tuy nhiên, thực tế, rất khác với lý thuyết, là mã có số lượng dòng lớn thường được viết mà không có thiết kế phù hợp. Do đó, yêu cầu ít dòng hơn CÓ THỂ buộc một số lập trình viên phải đưa ra thiết kế tốt hơn nếu họ có khả năng. Vấn đề là nhiều lập trình viên không có, thì yêu cầu không giúp được gì nhiều.

Tôi sẽ không xem số lượng dòng là một vấn đề trong các trường hợp thông thường, nhưng nó có thể chỉ ra các vấn đề. Nếu ai đó chỉ cho bạn một lớp có 1000 dòng mã, thì có gì đó không ổn với cách mà lớp được thực hiện hoặc thiết kế.

Ví dụ của bạn chỉ ra một trường hợp trong đó số lượng dòng mã lớn hơn có ý nghĩa. Nhưng đó là ví dụ. Mỗi ngày tôi đều thấy các ví dụ trong đó số lượng dòng được gắn liền với việc thiếu kế hoạch

LỘC là một cách hữu ích hơn khi bắt đầu một dự án so với trong quá trình thực hiện thực tế, tôi nghĩ vậy. Biết LỘC trên mỗi điểm chức năng cho phép bạn ước tính nỗ lực của dự án và từ đó dự án sẽ mất bao lâu và số lượng nhà phát triển tối ưu.

Nó cũng có thể ảnh hưởng đến thiết kế và lựa chọn ngôn ngữ: giảm điểm chức năng hoặc chuyển sang ngôn ngữ có LỘC / FP thấp hơn sẽ làm giảm nỗ lực dự án, tất cả những thứ khác đều bằng nhau.

Các dòng mã không quan trọng lắm. Một cách để xem xét nó là so sánh nó với văn xuôi. Nhận thức đầu tiên là một thuộc tính quan trọng của cả mã và văn xuôi (giả sử tính chính xác) là khả năng đọc. Khả năng đọc (và dễ hiểu) giúp với các tính chất khác như khả năng bảo trì và tính chính xác.

Có những lợi thế để có thể phù hợp với một chức năng trong một số ít dòng. Nhưng có văn bản mà không có đoạn văn làm giảm mức độ dễ đọc của nó. Sử dụng các khái niệm khó, từ khó (hiếm) và cách diễn đạt phức tạp thường làm giảm lượng từ cần thiết để diễn đạt ý tưởng, nhưng đồng thời chuyển cấp độ đọc của văn bản từ cấp trung học lên học thuật chuyên nghiệp (trong trường hợp văn xuôi).

Nói chung, rất hữu ích khi thêm các tóm tắt trong mã của bạn và sử dụng các trình trợ giúp, v.v. nhưng một lần nữa, các trừu tượng đó có thể trở nên quá nhiều. Điều cũng có thể xảy ra là việc chuyển sự phức tạp sang một phần khác của mã. Đôi khi, giống như khi bạn là một chuyên gia đang thiết kế một khung / thư viện để sử dụng bởi các lập trình viên cơ sở (hoặc sinh viên), đó là một ý tưởng tốt để làm điều này. Nhưng đừng hy vọng các đàn em có thể hiểu được cách thức hoạt động của mã của bạn, chỉ khiến họ rất khó sử dụng nó không chính xác.

Khi viết mã, đặc biệt đừng ngại thêm các dòng trống trong mã của bạn. Chúng hoạt động như các đoạn văn và giúp bạn tách các phần khác nhau của chức năng của bạn (ngay cả khi chúng chưa được đưa vào trợ giúp).

Vấn đề lớn với mọi phương pháp đánh giá mã chính thức là nó chắc chắn sẽ thất bại trên một số mã. Điều này là do lập trình là một loại nghệ thuật và do đó, không thể tồn tại các tiêu chuẩn rõ ràng để đánh giá. Tất nhiên có nhiều loại nghệ thuật khác nhau - sản xuất hàng loạt các bức tranh cũng tồn tại, và có thể trong kinh doanh này, điều quan trọng là có bao nhiêu sơn dành cho một bức tranh. :)

Thành thật mà nói, tôi không nói quá nhiều về phép đo LỘC. Chắc chắn, thật tốt khi một chức năng hoặc thủ tục càng ngắn càng tốt, nhưng tôi lấy mã có thể đọc được trong thời gian ngắn bất kỳ lúc nào trong ngày.

Tôi đồng ý rằng luôn luôn yêu cầu giảm LỘC sẽ dẫn đến một mã khó đọc.

Tuy nhiên, có thể phong cách mã hóa của bạn quá dài dòng và người đánh giá của bạn nghĩ rằng một cách ngắn gọn hơn là tốt hơn. Ví dụ, một nhận xét chỉ giải thích một tuyên bố khá rõ ràng nhờ sự lựa chọn rõ ràng về tên biến là vô ích.

Chỉ có một điều mà các dòng mã đo lường và đó là số lượng dòng mã bạn có. Mọi thứ khác là không khí nóng, đầu cơ và định kiến.

Có rất nhiều ví dụ tuyệt vời trong các câu trả lời khác về việc làm thế nào có ít dòng mã hơn có thể làm cho điều gì đó tồi tệ hơn, không tốt hơn, nhưng một điểm cốt lõi dường như đã bị bỏ qua, và đó là: bạn thực sự cần bao nhiêu dòng để thực hiện công việc này ?

Nếu hoàn thành nhiệm vụ của bạn cần 10 dòng mã, vì vậy, bạn sẽ thực hiện trong 10 dòng. Nếu hoàn thành nó cần 10.000 dòng, thì cũng vậy, bạn hãy thực hiện nó trong 10.000 dòng. Việc sùng bái "ít dòng mã hơn" sẽ không làm cho ví dụ sau trở nên tốt hơn nếu bạn thực hiện nó trong 1.000 hoặc 2.000 hoặc bất cứ điều gì. Công việc cần 10.000 dòng và 10.000 dòng đó có thể bao gồm các lớp xác nhận, kiểm tra lỗi, bảo mật, v.v. sẽ bị bỏ qua nếu bạn thực hiện ít hơn.

Biên tập

Vì điều này đã thu hút được một số ý kiến ​​trái chiều, tôi nghĩ rằng tôi cần phải cụ thể hơn về những gì tôi đang nói ở đây. Điều đầu tiên mà bất cứ ai cũng nên làm là đọc điều này - điểm mà tôi đang yêu cầu bạn tránh xa nó là mã cấp cao bạn viết có thể mang ít hoặc không giống với mã máy thực sự được thực thi. Sự liên quan của điểm này là việc tập trung vào mã cấp cao mà không hiểu về những gì thực sự diễn ra bên dưới là sai lầm.

Bây giờ hãy xem xét những điều sau đây:

• Có thể viết mã thực sự xấu, chậm chỉ bằng một dòng duy nhất - lưu ý nhận xét về toán tử ternary ở cuối liên kết tôi cung cấp.

• Nếu một dòng mã thực hiện cuộc gọi API (hoặc cuộc gọi khác vào thư viện bên ngoài) thì bạn có định nghĩa rất ít theo cách kiểm soát trực tiếp đối với những gì được thực thi hoặc hiệu quả của nó.

• Lỗi kiểm tra, dọn dẹp, v.v ... tất cả đều thêm các dòng mã bổ sung và tôi khá chắc chắn rằng ngay cả những người hâm mộ cuồng nhiệt nhất với ít dòng mã hơn sẽ không tranh cãi với các dòng mã đó .

Vì vậy - các dòng mã là một số liệu bị hỏng. Ít dòng mã hơn không đảm bảo hiệu suất bổ sung - rằng lệnh gọi API hoặc thư viện là một dòng và có thể nằm ngoài tầm kiểm soát của bạn. Ít dòng mã hơn không đảm bảo độ mạnh hơn - kiểm tra lỗi và dọn dẹp sẽ luôn yêu cầu thêm dòng. Ít dòng mã hơn thậm chí không đảm bảo khả năng đọc hoặc bảo trì thêm - bạn chỉ cần nhìn vào IOCCC để biết điều đó.

Vì vậy, những gì ít dòng mã đảm bảo? Ít dòng mã hơn, đó là tất cả.

Thật sai lầm khi tập trung vào làm cùng một công việc trong 2.000 dòng so với 10.000. Thay vào đó tập trung vào mã hoạt động, mạnh mẽ, thực hiện trong phạm vi dung sai được chấp nhận và dễ đọc hơn và duy trì trong tương lai. Đôi khi điều đó có nghĩa là bạn có thể làm điều đó với số lượng LoC thấp, đôi khi điều đó có nghĩa là bạn phải làm điều đó với số lượng LoC cao hơn, nhưng số lượng LoC không nên là điều quan trọng ở đây.

Làm thế nào là quan trọng để giảm số lượng dòng trong mã? Trong hầu hết các trường hợp, không phải ở tất cả. Trong thực tế, trong hầu hết các trường hợp, điều quan trọng hơn là tăng số lượng dòng mã bằng cách chia các hoạt động phức tạp thành các bước dễ đọc hơn và nhận xét từng bước cũng như thêm nhận xét nói chung để làm cho mã dễ đọc và mở rộng hơn nhà phát triển đến sau bạn.

Trong giai đoạn trước, người ta đã giả sử rằng nếu số lượng dòng mã là loc thì mã đó có hiệu lực và nó hoàn thành tất cả các nhiệm vụ mà nó được sử dụng để thực hiện nhưng sau đó, nó đã nhận ra ít hơn có hiệu quả do chi phí mà hệ thống phải chịu khi thực thi mã là rất ít. Vì vậy, việc cải thiện hệ thống được tạo ra ít hơn. Vì vậy, người ta cho rằng shoul loc sẽ ít hơn. Để giảm bớt các yếu tố sau nên được đưa vào tài khoản.

1. Lập sơ đồ vấn đề của bạn
2. Cố gắng sử dụng số vòng lặp ít hơn có thể
3. Các cuộc gọi chức năng không nên nhiều
4. Các cấu trúc dữ liệu mới như TRIE nên được sử dụng trong trường hợp ngăn xếp hoặc hàng đợi được sử dụng để lưu trữ thông tin liên quan.
5. Và hãy cố gắng giải quyết vấn đề bằng một cách tiếp cận thực tế thay vì tưởng tượng trong đó bạn đang lưu trữ một số lượng lớn trong một mảng rất lớn và sau đó cố gắng truy cập nó thông qua mảng.]
6. Sử dụng càng nhiều macro càng tốt Cách tiếp cận sử dụng cũng phụ thuộc vào vấn đề. Nếu nó thực sự phức tạp thì đôi khi sử dụng cách tiếp cận đơn giản cũng tương đương với cách tiếp cận phức tạp