Xử lý món súp giòn

Tôi đã lập trình trong cả C # và VB.NET trong nhiều năm, nhưng chủ yếu là VB. Tôi đang chuyển hướng nghề nghiệp sang C # và nói chung, tôi thích C # hơn.

Tuy nhiên, một vấn đề tôi gặp phải là súp giòn. Trong VB, mỗi từ khóa cấu trúc có một từ khóa đóng phù hợp, ví dụ:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

Mã tương tự được viết bằng C # kết thúc rất khó đọc:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

Đã quá quen với VB, tôi tự hỏi liệu có một kỹ thuật được sử dụng bởi các lập trình viên kiểu c để cải thiện khả năng đọc và để đảm bảo rằng mã của bạn kết thúc trong "khối" chính xác. Ví dụ trên tương đối dễ đọc, nhưng đôi khi ở cuối đoạn mã tôi sẽ có 8 cấp độ niềng răng xoăn trở lên, yêu cầu tôi cuộn lên nhiều trang để tìm ra dấu ngoặc nào kết thúc khối mà tôi quan tâm trong.

Đặt nẹp xoăn bắt đầu của bạn trong cùng một "thứ hạng" như kết thúc của bạn, như thế này:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• Tùy thuộc vào IDE của bạn: đặt con trỏ của bạn ở nẹp mở / đóng và nó sẽ làm nổi bật cả dấu ngoặc đó và dấu ngoặc tương ứng.
• Thu gọn khối và nó cho bạn thấy nơi nó mở / đóng.
• Viết các khối mã nhỏ hơn. Nghiêm túc. Kiểm tra Clean Codevà không bao giờ gặp phải vấn đề này nữa (và có mã dễ đọc / dễ bảo trì hơn).

Một lưu ý, sau đây là cú pháp c # hợp lệ có thể giúp ích cho tình huống cụ thể của bạn:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

Một quy ước chung là thêm một nhận xét sau dấu ngoặc nhọn để chỉ ra cấu trúc mà nó đóng:

if {
   ...
} // end if

while (condition) {
   ...
} // end while

vv Tôi đã không bao giờ ấm áp với hội nghị này bản thân mình, nhưng một số người thấy nó hữu ích.

Nói chung, khi khó kết hợp niềng răng theo bất kỳ phong cách nào - điều đó có thể có nghĩa là phương pháp này quá dài và nên được áp dụng lại.

Tôi nghĩ rằng bạn cần phải cứng rắn với niềng răng. Cuối cùng, chúng sẽ trở thành bản chất thứ hai đối với bạn và bạn sẽ tự hỏi làm thế nào bạn sống mà không có chúng.

Hãy chắc chắn rằng chúng được thụt lề một cách thích hợp, và một số quy ước khoảng cách đang được tuân theo (không quan trọng).

Tôi loại bỏ 2 cấp độ lồng nhau bằng cách thu gọn không gian tên và phạm vi lớp theo chiều ngang. Lưu ý các phương thức được tuôn ra với cạnh trái của màn hình. Tôi không thấy điểm mất 2 cấp độ thụt trong mỗi tệp.

Sau đó, hiếm khi bạn làm tổ sâu hơn 4 cấp.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Gần đây tôi đã quyết định thử và chính thức hóa hai quy tắc về các cấu trúc kiểm soát dòng chảy về cơ bản như sau:

• Bạn không nên có gì ngoài các cấu trúc dòng mã cần thiết
• Bạn nên làm cho các cấu trúc dòng mã càng nhỏ càng tốt

Đối với chính xác những lý do bạn đã đề cập và nhận thức rõ ràng, tôi nghĩ đây là những quy tắc tuyệt vời để tuân theo. Có một vài kỹ thuật đơn giản bạn có thể sử dụng để thực hiện chúng:

• Thoát khỏi phạm vi ngay khi bạn có thể (điều này bao gồm phạm vi của các vòng lặp cũng như các chức năng)
• Theo dõi các elses có thể được giảm thiểu bằng cách thoát khỏi hàm trước đó và áp dụng kỹ thuật thoát phạm vi như tôi đã đề cập
• Đảo ngược kiểm tra có điều kiện của bạn khi mã bên trong nếu lớn hơn bên ngoài
• Mã yếu tố bên trong một vòng lặp ra một phương thức khác khi kích thước của vòng lặp phát triển để che khuất phần còn lại của phương thức
• Theo dõi bất kỳ phạm vi nào chỉ chứa phạm vi khác, ví dụ, một hàm có toàn bộ phạm vi được điền bởi một if không có gì ngoài if

Tôi đã nêu chi tiết ở đây các ví dụ về cách không tuân theo những điều này có thể khiến bạn làm như bạn đã nói và đặt mã vào khối mã sai, điều này rất tệ và là nguyên nhân dễ gây ra lỗi trong quá trình bảo trì.

Thật không may, đây là một trong những nguyên nhân lâu đời nhất của chiến tranh trong điện toán. Có thể đưa ra những lý lẽ hợp lý từ cả hai phía (nền kinh tế bất động sản theo chiều dọc tốt hơn so với khả năng dễ dàng hơn để khớp trực quan với cú đúp mở), nhưng trong thực tế, một trình định dạng mã nguồn đơn giản sẽ giải quyết mọi thứ cho bạn. MS Visual C # có một tích hợp hoạt động tốt.

Tuy nhiên, được cảnh báo rằng nếu bạn đang làm việc như là một phần của một nhóm, bạn sẽ phải tuân thủ các quy ước được sử dụng bởi nhóm đó, do đó, bạn phải trả tiền để làm quen với cả hai phong cách và không được tôn giáo theo kiểu niềng răng.

Vì vậy, trong khi bạn đang học bằng mọi cách có nghĩa là tập trung vào phong cách giúp bạn dễ học hơn, nhưng hãy để mắt đến người khác trong khi bạn ở đó và bạn sẽ làm tốt.

Sử dụng Resharper, sẽ giúp đề xuất các cách để giảm lồng. Ngoài ra, hãy đọc cuốn sách Clean Code của Bob Martin , trong đó nhấn mạnh rằng một chức năng chỉ nên làm một việc, và do đó mỗi chức năng chỉ nên dài nửa tá dòng, vì vậy bạn sẽ không phải lo lắng về nhiều cấp độ.

Có một tiện ích bổ sung cho trình chỉnh sửa có thể giúp bạn tại: C # Outline .

Tiện ích mở rộng trình soạn thảo VS20xx cho C # bằng cách thêm các tính năng để thu gọn, mở rộng và làm nổi bật các khối mã lồng nhau. Các tính năng này cho phép chỉnh sửa và đọc nội dung lồng nhau của các khối mã dễ dàng hơn như if, while, v.v.

Nếu bạn viết Mã của mình trong Visual Studio, thì cũng có một Plugin hiển thị cho bạn các dấu chấm dọc giữa điểm đầu và điểm cuối của mọi cấu trúc mà bạn xây dựng.

Nhưng nhìn chung, tôi nghĩ rằng sẽ mất một chút thời gian cho đến khi bạn quen với "xoăn-niềng-súp". (Btw, tôi thực sự thích biểu hiện đó. Nghe có vẻ giống như một Tên Tập cho Lý thuyết Vụ nổ lớn)

Sự thụt lề cho bạn biết bạn đang ở đâu, trong cả hai kiểu cú pháp. Nếu bạn viết chương trình VB hoặc chương trình C # trên một dòng, bạn sẽ sớm không thể biết được bạn đang ở đâu trong cú pháp lồng nhau. Máy phân tích các cụm từ kết thúc khối hoặc dấu ngoặc nhọn, nhưng con người cần thụt lề.

Các cụm từ kết thúc xuất phát từ một kỷ nguyên của thẻ đục lỗ và băng giấy, khi lập trình ít tương tác và trực quan hơn nhiều. Hoặc, thực sự, không tương tác chút nào. Rất khó để vào các chương trình, và vì vậy các lập trình viên cần trình biên dịch phải rất thông minh về phân tích cú pháp và phục hồi lỗi.

Trong thời đại đã qua, chu trình biên dịch-biên dịch có thể liên quan đến việc chuẩn bị thẻ đục lỗ bằng máy bấm thẻ, sau đó xếp hàng vào cửa sổ nộp công việc trong đó một nhân viên lấy thẻ đục lỗ và gửi chúng vào máy. Sau đó, lập trình viên sẽ thu thập đầu ra (in trên giấy) từ một cửa sổ khác. Nếu chương trình có lỗi, đầu ra sẽ chỉ bao gồm chẩn đoán trình biên dịch. Khi thời gian quay vòng dài, chi phí gõ end ifthay vì chỉ )là hợp lý nếu nó giúp cải thiện chất lượng chẩn đoán, bởi vì lập trình viên cần sửa càng nhiều lỗi càng tốt trong một lần lặp để giảm số lần lãng phí thời gian lặp đi lặp lại qua cửa sổ trình công việc.

Khi thiếu một nẹp xoăn đóng, thật khó để biết niềng răng mở nào là không được đóng. (Trình biên dịch có thể phải phân tích thụt lề để đưa ra phỏng đoán có giáo dục.) Nếu bạn xóa một dấu ngoặc đóng bên trong một hàm, thì có vẻ như toàn bộ phần còn lại của tệp là một phần của hàm đó, dẫn đến một loạt các thông báo lỗi không hữu ích. Trong khi nếu bạn có một end functioncú pháp, trình biên dịch có thể suy ra nơi hàm bị lỗi kết thúc, phục hồi và phân tích các hàm tiếp theo đúng cách, cung cấp cho bạn chẩn đoán bổ sung, nếu có, có ý nghĩa.

Khi bạn đang làm việc trong trình soạn thảo văn bản nhận biết mã tự động thụt lề và tô màu mã của bạn, trên màn hình độ phân giải cao nơi bạn có thể thấy sáu mươi dòng trở lên, các đối số cho các loại ngôn ngữ vụng về đó không còn được áp dụng. Bạn có thể dần dần chỉnh sửa và xây dựng lại các chương trình nhanh đến mức bạn chỉ có thể xử lý một lỗi tại một thời điểm. Hơn nữa, bằng cách xem các phần lớn của chương trình đồng thời trên màn hình và duy trì thụt lề thích hợp, bạn có thể giảm sự xuất hiện của các loại lỗi lồng nhau đó ngay từ đầu. Và trình soạn thảo văn bản lập trình tốt thậm chí sẽ gắn cờ một số loại lỗi cú pháp khi bạn nhập. Hơn nữa, có các trình soạn thảo gấp sẽ thu gọn các khối của chương trình dựa trên cú pháp của nó, đưa ra một khung nhìn "giống như phác thảo" về cấu trúc của nó.

Lisp đã sử dụng dấu ngoặc đơn ngay từ đầu và có lẽ, không phải ngẫu nhiên, tin tặc Lisp đã tiên phong lập trình như một trải nghiệm tương tác bằng cách xây dựng các hệ thống chấp nhận các chương trình trong các đoạn nhỏ (biểu thức).

Thực tế, bạn hoàn toàn không cần biểu tượng kết thúc, như ngôn ngữ Python minh họa. Việc xác định chỉ có thể là cấu trúc. Con người đã sử dụng thụt lề để mò mẫm cấu trúc mã ngay cả trong các ngôn ngữ mà máy phụ thuộc vào các ký hiệu hoặc cụm từ kết thúc.

Nếu bạn đang sử dụng IDE, chỉ cần nhấn Crtl+ k+ Dvà IDE sẽ thực hiện phần còn lại của công việc.