같은 역할의 변수를 네이밍 하는 방법?

🎓 모두의 Q&A
1

image
머리가 쪼개 집니다.

string LocalDisk1 = "C:\\";  //LocalDiskC = "C:\\";
string LocalDisk2 = "D:\\";  //LocalDiskD = "D:\\";

int PageNumber1 = 2;    //IntroducePage = "2";
int PageNumber2 = 6;    //NamingPage = "6"; 

string variable1;
string variable2;

void DuplicateRequest(string variable1, string variable2)
{
    CallMethod(variable1);
    CallMethod(variable2);
}

변수의 역할이 동일한 경우 네이밍이 어렵네요;;;
(비슷한 의미의 변수이지만 Value만 다른 경우…)
조언 부탁드립니다.

5개의 좋아요
2

정말로 동일하다면 하나의 목록이 됩니다.

6개의 좋아요
3

@dimohy 목록이 된다는 건 어떤 의미일까요?
배열을 사용하지 못하는 상황이라…

5개의 좋아요
4

image 변수명을 코딩 고수처럼 변경해줘

string primaryDiskDrive = "C:\\";
string secondaryDiskDrive = "D:\\";

int introductionPageNumber = 2;
int namingPageNumber = 6;

string firstVariable;
string secondVariable;

void ExecuteDuplicateRequest(string firstVariable, string secondVariable)
{
    CallMethod(firstVariable);
    CallMethod(secondVariable);
}
5개의 좋아요
5

닷넷 어셈블리를 통해 비슷한 경우에는 어떻게 네이밍을 했는지 참고하면 좋더라고요!

5개의 좋아요
6

혹시 배열(혹은 나열형)을 사용 할 수 없는 이유를 알려 주실 수 있을까요?
어떤 상황인지 쬐끔 궁금해져서…

3개의 좋아요
7

Azure pipeline parameters(YML)를 설정하는 부분 입니다.
variable을 배열 설정하는 부분은 있는데,
Parameters를 배열로 설정하는 방법은 안보이네요;;

3개의 좋아요
8

parameters 를 사용해서
나열을 사용 할 수 있습니다.

parameters:
- name: 'LocalDisk'
  default:
    - C
    - D
    - E

each 사용

{ each param in parameters.LocalDisk }

라고 gpt를 먹은 bing이 알려주네요 !

4개의 좋아요
9

제 경험 상, 모든 변수 이름을 RESTful 하게 지으면, 인텔리센스와 같은 코드 헬퍼가 문제를 일으킬 때 자괴감이 듭니다.

특히, 대부분의 IDE 는 일정 수준의 편집 히스토리가 넘어가면, 느려지거나 버벅이기 마련입니다. 이때 코드 헬퍼도 함께 느려지고, 그 느려짐은 내 손가락이 매워야 하죠. ^^

저는, 로컬 변수(혹은 식별자)와 그 외 변수(혹은 식별자)로 나눠서 생각합니다.

로컬 변수는 수명이 짧기 때문에, 변수의 이름이 코드의 가독성에 미치는 영향이 크지 않기에 짧고 간결하게 짓습니다.

로컬 변수의 의미가 중요할 정도로 메서드의 범위가 넓다면, 그것은 잘 못된 설계일 확률이 높았습니다.
로컬 변수들에 구분이 중요할 정도로 개수가 많은 것도 설계상의 오류인 경우가 많았습니다. 이 경우, 개수 만큼 할당도 많이 일어나기에, 보이지 않는 성능 구멍으로 작용했습니다.

로컬 변수 이외의 식별자들은 사용자 코드 입장에서 읽기 편하도록 만듭니다.

enum Drive { C, D, E, }
// enum LocalDrive { C, D, E , } => 약간 중복적. 역전앞 같은 느낌.

// 확장 메서드의 자기 변수는 사용자에게 공개되지 않습니다.
public static string ToPathHeader(this Drive d)
=> d.ToString() + @":\";

// 공개되는 매개변수는 메서드 이름과 호응되도록
public static string Lead(this Drive d, string directory)
=> d.ToPathHeader() + directory;

.

위의 코드에 나타난 식별자들은 나름 이유있는 이름을 가지고 있지만, 사용자 코드 입장에서는 뭔가 어색합니다.

var c = Drive.C;
var d = Drive.D;

var cph = c.ToPathHeader();
var dph = d.ToPathHeader();

var f1 = @"temp\temp1.txt";
var f2 = @"temp\temp2.txt"

var f1Path = c.Lead(f1);
var f2Path = c.Lead(f2);

사용자의 코드가 자연스럽게 읽히지도 않을 뿐더러, 모든 로컬 변수들은 모두 string 인데, 이를 말해주는 단서가 하나도 없습니다.

그래서, 사용자 코드를 읽기 쉽게 만들고, 형식에 대한 단서를 제공하기 위해 아래와 같이 변경합니다.

public static string ToPathString(this Drive d)
=> d.ToString() + @":\";

public static string ToPathString(this Drive d, string directory)
=> d.ToPathString() + directory;

//혹은
public static string ToPathString(this Drive d, string directory = string.Empty) 
=>  d.ToPathString() + directory;

사용자 코드

var c = Drive.C;
var d = Drive.D;

var cPath = c.ToPathString();
var dPath = d.ToPathString();

var f1 = @"temp\temp1.txt";
var f2 = @"temp\temp2.txt"

var f1Path = c.ToPathString(f1);
var f2Path = c.ToPathString(f2);

cPath 가 로컬 변수가 아닌 클래스의 멤버로 정의되는 경우라도, 비 공개 멤버라면 로컬변수처럼 지어도 무방하다고 생각합니다. 이 경우, 생성자가 아닌 선언초기화 문법으로 초기화 하는게 가독성 측면에서 더 좋더군요.

// 생성자 초기화
readonly string _cPath;
public MyType()
{
    _cPath = Drive.C.ToPathString();
}

// 선언 초기화
readonly string _cPath = Drive.C.ToPathString();
7개의 좋아요
10

저는 동일한 역할의 변수는 나름의 순서가 있다면 first, second나 primary, secondary 등을 붙여 명명하고, 그렇지 않다면 그냥 단순하게 arg0, arg1 같은 식으로 명명합니다.

변수명에 의미를 담는 이유도 결국 가독성을 위해서이므로, 메서드의 이름을 잘 짓거나 적절히 summary를 해놓는다면 매개변수의 역할도 쉽게 이해할 수 있지 않을까 싶습니다.

5개의 좋아요
11

루나시아 님 의견에 동의 합니다.

한가지 예로 C++의 표준 바인딩을 보면 api의 arg까지 바인딩을 할 경우 placeholders를 이용하는데요.
보면 placeholders::_1 ~ _20 까지 있습니다.
뭐 어쩔 수 없는 경우에는 써야 한다는 하나의 예가 아닐까 생각 되네요.
저는 메인이 C++이라 자꾸 이쪽 얘기를 하게 되네요. ㅎ

5개의 좋아요