Câu hỏi về chất lượng câu hỏi F #

Question

Tôi bắt đầu viết mã bằng F # khoảng 2 tháng trước.

Tôi rất thích thú với ngôn ngữ lập trình này. Tôi đến từ một nền C#, và mỗi khi tôi cần phải quay trở lại C#, nó cảm thấy rất cồng kềnh và cồng kềnh.

Nhưng vẫn có những điều tôi nghĩ là có vấn đề trong F #, và đây là những gì câu hỏi của tôi có liên quan đến:

1. Không có tự động hoàn thành như VS có cho C# đúng không? Ví dụ. bên trong một hàm nhận tham số aParameter, nếu tôi viết aPara no auto complete sẽ xuất hiện. Có một chức năng bên trong VS có thể giải quyết vấn đề này và tôi không biết?

2. Gỡ lỗi là tẻ nhạt để nói ít nhất. Vì F # hỗ trợ đường ống/chuỗi hoặc bất cứ điều gì bạn muốn gọi nó, tôi thường cố gắng để chuỗi càng nhiều thứ càng tốt (bất cứ nơi nào nó có ý nghĩa tất nhiên). Ví dụ:

   correctedData 
   |> List.filter (fun (_, r, _) -> r <= 3) 
   |> Seq.ofList 
   |> Seq.groupBy (fun (_, r, cti) -> (r,cti))        
   |> Seq.map (fun ((r,cti),xs) -> (r, cti, Seq.length xs)) 
   |> Seq.toList 
   

Và đây chỉ là phần tư toàn chaining tôi thực hiện. Bất cứ khi nào tôi mess một cái gì đó lên trong các chuỗi, tôi tìm thấy nó rất rất khó để gỡ lỗi, nơi tất cả đã đi sai.

Tôi có đang làm sai chuỗi này (lạm dụng nó) không? Theo quan điểm của tôi, không có gì trung gian từ chuỗi này có ý nghĩa tồn tại một cách nguyên tử, do đó không có lý do gì để có giá trị trung gian. Nhưng vì quan điểm ngữ nghĩa này, tôi cũng mất đi sức mạnh của việc có các giá trị trung gian giúp tôi gỡ lỗi. Vì vậy, sau đó tôi phải chèn chúng vào mã, gỡ lỗi, sau đó loại bỏ chúng một lần nữa. Nhưng đây là một nỗ lực lãng phí. Có cách nào để khắc phục điều này?

Ngoài ra, gỡ lỗi chức năng ẩn danh List.map bên trong một chuỗi cảm thấy một lần nữa khó xử và khó so với ví dụ: một vòng lặp for.

Tôi chắc chắn rằng tôi đang thiếu thứ gì đó và cách gỡ lỗi hiện tại của tôi có lẽ không tối ưu - không phải bởi một cảnh quay dài - vì vậy mọi đề xuất đều được hoan nghênh.

Answer 1

1.There là không tự động hoàn chỉnh như VS có cho C# đúng

Có tính năng tự động hoàn chỉnh cho F #. Nó không được kích hoạt tự động khi bạn bắt đầu gõ mặc dù. Nếu bạn đang ở trong Visual Studio và nhập aPara và sau đó nhấn Ctrl + Không gian, nó sẽ được tự động hoàn thành để aParameter nếu nó nằm trong phạm vi. Tương tự, bạn có thể thực hiện việc này trong phạm vi cấp cao nhất để xem các loại và không gian tên có sẵn. Tự động hoàn thành cũng được kích hoạt tự động khi bạn gõ .

2.Debugging là tẻ nhạt để nói rằng ít nhất

Tôi đồng ý với điều này - gỡ rối, ẩm ướt (đặc biệt là với chuỗi lười biếng) là khéo léo. Đây là một chút khó hiểu ngay cả khi bạn đang ở trong C#, nhưng C# làm công việc đáng ngạc nhiên tốt trên này. Có hai cách để giải quyết vấn đề này:

• Sử dụng F # Tương tác hơn. Tôi viết hầu hết mã của mình trong tập tin F # Script trước tiên, nơi bạn có thể chạy các giải pháp hoàn chỉnh một phần của mình và xem kết quả ngay lập tức.Đối với tôi, điều này khá nhiều thay thế gỡ lỗi, bởi vì khi mã của tôi hoàn thành, tôi biết nó hoạt động.

• Bạn có thể xác định hàm tap làm cho dữ liệu trong đường ống và cho phép bạn xem nội dung đang đi qua đường ống. Tôi không sử dụng này rất nhiều, nhưng tôi biết một số người như nó:

  let tap data = 
      let materialized = List.ofSeq data 
      materialized 
  

  Sau đó, bạn có thể sử dụng nó trong đường ống của bạn:

  correctedData 
  |> List.filter (fun (_, r, _) -> r <= 3) 
  |> tap 
  |> Seq.groupBy (fun (_, r, cti) -> (r,cti))        
  |> tap 
  |> Seq.map (fun ((r,cti),xs) -> (r, cti, Seq.length xs)) 
  |> Seq.toList 
  

  này cho biết thêm một số tiếng ồn để các đường ống dẫn, nhưng bạn có thể gỡ bỏ nó một lần nữa khi bạn đã hoàn tất việc gỡ lỗi.

Answer 2

Câu hỏi về cải thiện trải nghiệm gỡ lỗi với F # có nhiều khía cạnh nên nó xứng đáng là một bài viết lớn. Vì vậy, tôi sợ câu hỏi sẽ được đóng lại.
Tuy nhiên, đây là hai thủ thuật gọn gàng mà tôi đang sử dụng. Tôi phải lưu ý rằng tôi cũng là một fan hâm mộ lớn của cách tiếp cận đường ống và vì vậy tôi phải đối mặt chính xác cùng một vấn đề.

Biết loại của bạn.

Có giá trị được luồn qua một chuỗi nhiều phép biến đổi có thể nhanh chóng dẫn đến khó nhớ các loại chính xác ở mỗi bước. Bí quyết là:

value 
|> transformation1 
|> fun x -> x 
|> transformation2 

này cho phép bạn:

1. thấy chính xác loại x trong thời gian thiết kế;
2. đặt điểm ngắt (đặt con trỏ tại cơ quan chức năng ) và xem giá trị tại thời gian gỡ lỗi;
3. Ngay cả khi bị quên trong mã sau khi thực hiện, điều này để lại dấu chân tối thiểu.

Điều kiện kết xuất giá trị cho bảng điều khiển.

Có lambdas phức tạp, điểm ngắt có thể không giúp được gì nhiều. Dưới đây là thêm một lừa, liên quan đến một trong những mô tả trong @Tomas' câu trả lời: viết một hàm nhỏ, như thế này:

let inline debug x = 
#if DEBUG 
    if System.Console.CapsLock then 
     printfn "%A" x 
     // obviously, it must not be necessarily printf; 
     // it can be System.Diagnostics.Debug.WriteLine() 
     // or any other logger tool that exists in the project. 
#endif 
    x 

Mã sử ​​dụng trông như thế này:

value 
|> transformation1 
|> fun x -> x 
|> debug 
|> transformation2 

Ý tưởng là:

1. bạn đặt điểm ngắt ngay trước cuộc gọi debug, giống như mô tả ở trên;
2. switch Caps Lock trên
3. và Step Over hoặc chỉ để cho các ứng dụng chạy

Nếu bạn có nhiều nơi debug gọi ngồi, họ sẽ không làm hỏng đầu ra.

Answer 3

Khi gỡ lỗi |> vấn đề đường ống - hãy thử có tiêu chuẩn mã hóa cá nhân mà bạn không có nhiều hơn ba hoặc tối đa bốn dòng trong đường dẫn như vậy. Khi họ nhận được lâu hơn thế, refactor. Đây là những gì tôi làm và nó giúp ích rất nhiều.