다음 fsharp 코드를 작성하는 것이 더 나은 (더 기능적인 방식입니까?)?

Question

나는 프로젝트에서이 같은 코드의 조각을 가지고 있고 그것이 기능적인 방법으로 기록되지 있어 실현 :

let data = Array.zeroCreate(3 + (int)firmwareVersions.Count * 27) 
data.[0] <- 0x09uy        //drcode 
data.[1..2] <- firmwareVersionBytes    //Number of firmware versions 



let mutable index = 0 
let loops = firmwareVersions.Count - 1 
for i = 0 to loops do 
    let nameBytes = ASCIIEncoding.ASCII.GetBytes(firmwareVersions.[i].Name) 
    let timestampBytes = this.getTimeStampBytes firmwareVersions.[i].Timestamp 
    let sizeBytes = BitConverter.GetBytes(firmwareVersions.[i].Size) |> Array.rev 

    data.[index + 3 .. index + 10] <- nameBytes 
    data.[index + 11 .. index + 24] <- timestampBytes 
    data.[index + 25 .. index + 28] <- sizeBytes 
    data.[index + 29] <- firmwareVersions.[i].Status 
    index <- index + 27 

firmwareVersions는 CSHARP 라이브러리의 일부 목록입니다. 바이트 배열을 으로 변환하는 방법에 대한 지식이 있습니다 (가지고 있으면 안됩니다). 나는 위의 코드는 매우 비 작동 실현, 그래서 나는 이런 식으로 변경 을 시도 :

let headerData = Array.zeroCreate(3) 
headerData.[0] <- 0x09uy 
headerData.[1..2] <- firmwareVersionBytes 

let getFirmwareVersionBytes (firmware : FirmwareVersion) = 
    let nameBytes = ASCIIEncoding.ASCII.GetBytes(firmware.Name) 
    let timestampBytes = this.getTimeStampBytes firmware.Timestamp 
    let sizeBytes = BitConverter.GetBytes(firmware.Size) |> Array.rev 
    Array.concat [nameBytes; timestampBytes; sizeBytes] 

let data = 
    firmwareVersions.ToArray() 
    |> Array.map (fun f -> getFirmwareVersionBytes f) 
    |> Array.reduce (fun acc b -> Array.concat [acc; b]) 

let fullData = Array.concat [headerData;data] 

를이 코드를 작성하는 더 나은 (더 많은 기능) 방법 경우 그래서 지금 내가 궁금하네요. 그렇다면 ... 개선해야하는 이유와 개선점은 무엇입니까? 그렇지 않은 경우 왜 대신 무엇을해야합니까?

의견, 의견, 비고?

는

업데이트

가 그냥 몇 가지 정보를 추가하고 싶었 감사드립니다. 이것은 바이너리 통신 프로토콜에 대한 데이터를 처리하는 일부 라이브러리의 일부입니다. 코드의 첫 번째 버전에서 볼 수있는 유일한 단점은 다른 언어로 프로토콜을 구현하는 사람들 (우리 상황에서도 마찬가지로 )은 각 부분이 차지하는 바이트 수를 더 잘 이해할 수 있다는 것입니다. 정확히 어디에 그들은 바이트 스트림에 위치하고 있습니다 ... 그냥 발언. (모두가 영어를 이해하지만, 모든 파트너는 코드를 읽을 수 있습니다.)

Answer 1

저는 색인 생성이 문제의 중요한 부분 인 오프셋의 더 나은 그림을 제공하기 때문에 첫 번째 버전을 더 좋아합니다. 명령형 코드는 바이트 오프셋을 눈에 잘 띄게 나타내며 파트너가 문서를 읽을 수 없거나 읽을 수없는 경우 중요 할 수 있습니다. 기능 코드는 함께 고정 된 구조를 강조합니다. 바이트 오프셋이 설명서에 언급 될만큼 중요하지 않으면 OK입니다.

색인 생성은 일반적으로 실수로 복잡하므로이 경우 피해야합니다. 예를 들어 첫 번째 버전의 루프는 for i = 0 to loops 대신 for firmwareVersion in firmwareVersion이 될 수 있습니다.

또한 Brian에 따르면 오프셋에 상수를 사용하면 명령형 버전을 훨씬 쉽게 읽을 수 있습니다.당신이 바이트의 위치를 ​​전달하려면

let fullData = 
    [|yield! [0x09uy; firmwareVersionBytes; firmwareVersionBytes] 
    for firmware in firmwareVersions do 
     yield! ASCIIEncoding.ASCII.GetBytes(firmware.Name) 
     yield! this.getTimeStampBytes firmware.Timestamp 
     yield! BitConverter.GetBytes(firmware.Size) |> Array.rev|] 

, 나는이 말에 의견에 넣어 것 :

Answer 2

얼마나 자주 코드가 실행됩니까?

'배열 연결'의 장점은 논리적 부분을보다 쉽게 ​​볼 수 있다는 것입니다. 단점은 많은 양의 가비지 (임시 배열 할당)를 생성하고 엄격한 루프에서 사용하는 경우 느려질 수도 있다는 것입니다.

또한 "Array.reduce (...)"는 "Array.concat"일 수 있습니다.

전반적으로 논리를보다 분명하게 보이도록 (예 : 명명 된 상수 HEADER_SIZE 등) 다른 방식으로 고려해보기는하지만 전체적으로 첫 번째 방법 (그냥 하나의 거대한 배열 만들기)을 선호합니다.

Google에서 논의하는 동안 몇 가지 주장을 추가하여 예를 들어 nameBytes는 예상 길이입니다.

Answer 3

나는 전체 프로그램은 짧은 너무 많이되기 때문에 모든 인라인 경사 할 것 각 라인.