C# 코드를 복잡하게 만들 수 있는 5가지 나쁜 습관 - 피하는 방법

C#으로 프로그래밍할 때 모범 사례를 따르고 있는지 어떻게 알 수 있습니까? 그리고 코드를 지저분하고 관리하기 어렵게 만드는 나쁜 습관을 어떻게 피할 수 있습니까? 이 기사에서는 5가지 일반적인 나쁜 습관을 살펴보고 몇 가지 더 나은 대안을 사용하여 이를 피하는 방법을 설명합니다.

if 문으로 null 확인 중지

if 문은 엄청난 수의 유틸리티와 용도를 가질 수 있습니다. 그 중 하나는 확인하는 데 사용하는 것입니다null. 이것이 올바른 방법이지만 조금 더 잘 설명할 수 있습니다.

나쁜 방법:

if (application != null)
{
    if (application.protected != null)
    {
        return application.protected.shieldLastRun;
    }
}

좋은 방법:

return application?.protected?.shieldLastRun;

null 검사에 if 문을 사용할 수 없다고 말하는 것은 아니지만 null 조건부(해당 기능이 구현된 목적)를 사용하면 코드를 더 깨끗하고 쉽게 읽을 수 있습니다.

📚자세한 내용은 Microsoft 문서를 확인하세요. Null coalescing operator

클래스 대신 튜플 사용

둘 이상의 결과를 반환하려는 경우 가장 먼저 해당 목적을 위한 클래스를 만드는 것이 가장 먼저 떠오를 것입니다. 이것은 올바른 방법이지만 최선의 방법은 아닙니다.

나쁜 방법:

public ApplicationInfo GetInfo()
{
    var application = new ApplicationInfo
    {
        Path = "C:/apps/",
        Name = "Shield.exe"
    };

    return application;
}

좋은 방법:

public (string Path, string Name) GetApplicationInfo()
{
    return ("C:/apps/", "Shield.exe");
}

이를 위해 tuples , 그의 기사 Mahesh Chand에서 Tuples in C#에 따르면 :

"Often, we want to return more than one value from a class method. Prior to the introduction of tuples in .NET, there were three common ways to do so.

• Out parameters
• Class or struct types
• Anonymous types returned through a dynamic return type Tuples solve this problem"

Mahesh Chand가 말했듯이 튜플은 이 문제를 해결합니다. 따라서 그것들을 사용하는 것이 새 클래스를 만드는 것보다 훨씬 더 나은 옵션입니다.

📚자세한 내용은 Microsoft 문서를 확인하세요. Tuple types in C#

비공개 멤버를 사용하여 수정 방지

구성원을 수정할 수 있는 기능이 있는 것은 좋지 않습니다. 수정할 수 있는지 없는지 주의해야 합니다.

나쁜 방법:

class Laptop
{
    public string Os{ get; set; } // can be modified
public Laptop(string os)
    {
        Os= os;
    }
}
var laptop = new Laptop("macOs");
Console.WriteLine(Laptop.Os); // Laptop os: macOs

좋은 방법:

class Laptop
{
    public string Os{ get; } // cannot be modified
public Laptop(string os)
    {
        OS = os;
    }
}
var laptop = new Laptop("macOs");
Console.WriteLine(Laptop.Os); // Laptop os: macOs

멤버를 수정하지 않을 경우 향후 우발적(또는 의도적) 수정을 방지하기 위해 set;를 사용하지 않는 것이 좋습니다.

📚자세한 내용은 Microsoft 문서를 확인하세요. Get & Set accessors

if-else 대신 조건 연산자 사용

종종 습관적으로 우리는 클래식if-else을 사용하는 데 익숙해지고 그게 다입니다. 나는 이것을 나쁜 습관으로 생각하고 싶지 않지만 더 좋은 방법이 있습니다.

나쁜 방법:

if (hasApplication)
{
   shouldProtect = true;
}
else
{
   shouldProtect = false;
}

좋은 방법:

bool shouldProtect = hasApplication ? true: false;

분명히 알 수 있듯이 if-else 와 유사한 대안이지만 삼항 조건 연산자?: 를 사용하면 읽고 이해하기가 훨씬 쉽고 더 깔끔한 코드를 얻을 수 있습니다.

📚자세한 내용은 Microsoft 문서를 확인하세요. Conditional operator

식별자 약어로 이니셜을 사용하지 마십시오.

깨끗한 코드에 대해 생각할 때 가장 먼저 발생하는 것 중 하나는 이니셜을 사용하여 식별자의 코드를 줄이는 것입니다. 이것은 좋은 습관이지만 매우 조심해야 합니다.

나쁜 방법:

//different identifiers but same abbreviation
private readonly SecurityManager _sm;
private readonly SoftwareManager _sm;

좋은 방법:

//No confusion
private readonly SecurityManager _securityManager;
private readonly SoftwareManager _softwareManager;

약어를 사용하려는 경우 향후 혼동을 피하기 위해 항상 두 번 생각하십시오. 여러 번 쉬운 것이 최적이 아닙니다.

📚자세한 내용은 Microsoft 문서 시리즈를 확인하세요. Naming Guidelines