문제

이 두 코드가 있습니다. 하나는 더 읽을 수 있습니까?

  1. 각각

    decimal technicalPremium = 0;
    foreach (Risk risk in risks)
    {
         technicalPremium = technicalPremium + risk.TechnicalPremium;
    }
    return technicalPremium;
    
  2. LINQ

    return risks.Sum(risk => risk.TechnicalPremium);
    
도움이 되었습니까?

해결책

코드에서 작동하는 팀이 LINQ 버전이 무엇을하는지 알고 내면의 작동을 알고 있다면 더 읽을 수 있습니다.

다른 팁

원하는 것을 사용하더라도 방법으로 숨기십시오.

return risks.SumTechnicalPremium();

어느 것도 아니다. 첫 번째는 더 장점이며 모든 사람이 이해할 가능성이 높습니다. 두 번째는 LINQ에 대한 지식을 가진 모든 사람이 더 간결하고 쉽게 이해할 수 있습니다.

나는 당신이 당신의 환경에 당신의 선택을 기반으로 할 수 있다고 말하고 싶습니다.

LINQ를 읽을 수있는 사람을 위해 LINQ ONE.

코드를 단계별로 해석 해야하는 사람 (Intellisense/Documentation을 사용하여 더 짧은 코드.

LINQ와 함께 가십시오. 설명이 필요하다고 생각되면 한 줄의 의견이이를 처리합니다. 사람들이 LINQ에 더 익숙해지면 의견이 필요합니다.

LINQ 코드는 매우 읽기 쉬운 자체 문서입니다.

첫 번째 옵션은 더 넓은 범위의 사람들에게 더 읽을 수 있습니다. 두 번째 옵션은 독자가 LINQ를 알고 있고 이해할 수 있다는 점에서 '입력 장벽'이 있습니다. 청중이 그 진입 장벽을 넘어 서면 더 간결하고 더 나을 수 있습니다.

두 번째 옵션은 더 효율적이어야한다는 점에서 더 낫다고 생각합니다. 그러나 무슨 일이 일어나고 있는지는 덜 분명합니다 (적어도 나에게).

LINQ를 모르기 때문에 첫 번째라고 말하고 싶습니다. 과도하게 문서화 될 위험이 있으면 무슨 일이 일어나고 있는지에 대한 간단한 설명이 있습니다. 또는 전혀 모르는 사람들에게 LINQ라고 말하십시오.

당신이 그것이 목적을 설명하는 의견을 제공한다면, 나는 LINQ 옵션으로 갈 것입니다.

LINQ에 대한 지식이없는 경우 첫 번째. 개발자는 누구나 첫 번째를 읽고 이해할 수 있습니다.

여기에는 가독성 문제가 없습니다. 합계를 클릭하고 F1을 누르십시오.

승리를위한 LINQ.

각 언어는 그러한 것들을 코딩하는 가장 좋은 방법을위한 규칙이 있으므로, 그 언어를 정기적으로 사용하는 사람들에게 가장 읽을 수있는 것은 보편적이지 않습니다. Java 또는 일반 C# 프로그래머의 경우 첫 번째 옵션이 더 읽을 수 있습니다. LINQ 또는 기능적 프로그래밍에 익숙한 누군가의 경우 두 번째는 더 읽기 쉬운 것입니다.

나는 C#을 모르지만 두 번째 대안은 나에게 훨씬 더 깨끗해 보이며 그것이 무엇을하는지 이해할 수있었습니다 (OK, 첫 번째 버전으로 추측과 크로스 점검 할 수 있습니다). 기능적 배경으로 인해 가능합니다. 그러나 처음에는 4 (!) 장소에서 TechnicalPremium을 찾아야합니다. 두 번째는 코드를 읽고 있다면 훨씬 짧고 이해하기 쉽습니다.

또는

10 진수 기술 프리미엄 = 0;

Foreach (위험 위험) TechnicalPremium = TechnicalPremium + Risk.TechnicalPremium;

기술 프리미엄 반환;

나는 사람들이 그들이 "LINQ를 모른다면"첫 번째를 좋아한다고 말하는 것을 본다. 예, C#을 모른다면 첫 번째는 읽을 수 없습니다. 이것은 "더 읽기 쉬운"의 문제는 아니지만 "우리는 어떤 언어 기능을 사용하고 있습니까?"

모든 사람이 싫어하는 언어/프레임 워크/도구 세트의 일부에 대해 팀과 대화를 나누고 한도를 제한하지 않습니다. 다른 모든 것은 표준 어휘의 일부로 간주되며 모든 사람은 유창 할 것으로 예상됩니다. 이 목록은 코딩 표준 DOC에 들어가야합니다.돌연변이 가능한 값 유형을 만들지 마십시오" 그리고 "비공개 회원의 사소한 속성을 귀찮게하지 마십시오".

LINQ가 "제외"목록에없는 한 두 번째 예는 다음과 같습니다. 멀리 첫 번째보다 읽기 쉽습니다. 왜요? 독자가 해독 할 메커니즘을 제시하는 대신 코드의 의도를 선언하기 때문입니다.

당신의 목표가 당신을 따라 올 수있는 "누구나"를 더 읽을 수 있도록하는 것이라면, foreach를 사용하십시오. 나는 언어의 기본 경험이있는 사람이라면 누구나 이해할 수 있어야한다는 것을 의미한다고 해석합니다. LINQ에 익숙하지 않고 여전히 VS2005 이하를 사용하는 사람의 경우 LINQ 구문은 혼란 스러울 것입니다.

나는 첫 번째 코드 조각이 확실히 더 읽기 쉽다고 말하며, 수업과는 다른 이름을 가진 가변 위험을 최소한 변수로 바꾸면 더욱 읽기 쉬울 것입니다. 배열 위험을 바꾸면 더 나을 것입니다.

LINQ가 더 널리 채택되면서 두 번째는 쉽게 이해 될 것이라고 말하는 사람들에게 동의합니다. 확실히 더 간결합니다.

그러나 디버깅의 용이성에 대한 우려가 있습니다. Foreach에서 코드를 통해 각 패스에서 수행하는 작업을 정확하게 보는 것이 훨씬 쉬운 것 같습니다.

나는 그것이 "읽기 쉬운"이 의미하는 바에 달려 있다고 생각합니다. 첫 번째 예는 프로그램 논리를 명확하게 나타내며 프로그래밍 배경을 가진 사람이라면 누구나 이해해야합니다.

나에게 두 번째 예제는 컨텍스트 (즉, 배열 (또는 다른 수집 유형)을 취하고 해당 배열의 각 요소에 대한 합계를 실행하는 컨텍스트를 기반으로 더 직관적입니다. 두 번째 예제가 덜 명확해질 수있는 유일한 장소는 실제 람다 표현 자체에서 특히 람다 또는 알라디에 대한 경험이없는 사람이 기능 프로그래밍에 대한 배경 지식을 가지고 있다는 것입니다.

.NET 프로그래밍에서 Lambdas가 더 널리 퍼져 있다고 생각합니다. 이것은 문제가되지 않을 것입니다. 그대로, 나는 .NET에서 lambda 표현식을 사용하는 방법의 기본 사항을 이해하는 데 매우 작은 학습 곡선이 있다고 생각합니다.

두 번째는 확실히. 합산만큼 간단한 일을하기위한 큰 코드 블록을 갖는 것은 불필요합니다. 나는 또한 LINQ가 무엇인지 모르겠지만 나에게 완벽하게 읽을 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top