typedef struct Node *ptrToNode;
typedef ptrToNode List
typedef ptrToNode Position
이렇게 포인터를 List나 Position 같은 이름으로 가려도됨?
자료구조 수업 떄는 이렇게 배웠는데 복습하는 중에 이런 코드는 오히려 코드 보는 사람을 헷갈리게 하는거 같아서
typedef struct Node *ptrToNode;
typedef ptrToNode List
typedef ptrToNode Position
이렇게 포인터를 List나 Position 같은 이름으로 가려도됨?
자료구조 수업 떄는 이렇게 배웠는데 복습하는 중에 이런 코드는 오히려 코드 보는 사람을 헷갈리게 하는거 같아서
저런 코드는 아무래도 안좋지. List가 우리가 생각하는 그 리스트가 아니고 실제로는 노드에 대한 포인터잖아
나도 그렇게 생각함 근데 조금 더 생각해 보면 c에 있는 배열도 근본적으론 포인터를 가린거기도 하고, 자바나 C#같은 언어도 이런 식으로 쓰는 경우가 많다 보니 이렇게 사용하면 가독성이 더 늘어나나? 그런 느낌이 들어서 그럼
맥락 이야기가 나와서 그런데 배열이랑 포인터는 유사성이 많지만 리스트와 노드에 대한 포인터는 그렇지 않아서 과연 맥락에 맞는 타입 정의일지 의문이야.
typedef가 앞으로 이 구현체를 list라 부르겠다고 말하는거니 맥락에만 맞으면 된다봄
워낙 좆대로 쓰는 사람이 많은 언어라서 뭐가 베스트 프렉티스인지 ㅁ?ㄹ겠음 이거 하지마라 저거 하지마라같은 가이드는 산더미처럼 있는데 실제로 오픈소스 프로그램들 코드 보면 하지말라는 짓 ㅈㄴ 많이 하드라
나도 포인터는 명시적으로 딱 보이게 써놓는게 낫다고 생각함 typedef로 가리지 말고...
학식때는 포인터를 숨겼고 현업와서는 안숨긴다 ㅋㅋㅋ 포인터 숨겨놓으면 나중에 필드 접근할때 -> 쓰는게 직관적이지 않아서 걍 안쓰게 되도라
결국 짠 사람은 아무리 개판으로 짜도 대충 알아먹음. 처음 보는 사람이 봤을때 얼마나 가독성이 높은가를 생각해야하는데, 저렇게 2중 3중으로 typedef 짜놓으면 상식적으로처음 봤을때 저걸 이해하기 위해서 navigation을 추가로 하고 ‘x가 y구나’라는걸 머리 속에 박아놔야 하니까 별로 좋은 practice는 아니라고 생각함
다만 전체 프로젝트 레벨에서 x를 y라고 하자! 라는 합의가 이뤄지고 사용된다면 괜찮다고 봄. 뭐 얼마나 그런 일이 많겠냐 마는, 우리 회사는 std도 한 번 랩핑해서 쓰는 지라(exception handling 때문에) 종종 있더라고