Skip to content

🚀 1단계 buildMethod를 Widget으로 분리하기 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Aug 28, 2022

Conversation

devsoupe
Copy link

No description provided.

'더 담으러 가기',
style: TextStyle(fontSize: 17),
),
Text('더 담으러 가기', style: TextStyle(fontSize: 17)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

테스트 해보니 어떤게 더 가독성이 좋으신거 같은가요?

Copy link
Author

@devsoupe devsoupe Aug 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

코딩 스탠다드 측면의 고민

플러터로 개발을 하려다 보니 trailing comma에 대한 코딩 스탠다드가 필요할것 같다는 생각이 들었습니다.
여러 방향으로 고민하고 다른 분들 의견을 들어보니 크게 3가지 방향으로 나눠지더라구요.

  1. 무조건 trailing comma를 사용한다.
  • 장점 : 일관성 측면에서 좋음
  • 단점 : 짧은 코드에 대한 가독성이 조금 떨어짐
  1. Column Line Length의 기본 제한(80)에 맞춰 코드 길이가 넘지 않으면 trailing comma를 사용하지 않고, 넘으면 자동 wrap을 사용하지 말고 trailing comma를 사용한다. 필요시 코드 가독성에 도움이 된다면 trailing comma 를 사용해도 된다.
  • 장점 : 한줄 사용으로 인해 짧은 코드 가독성이 높아짐. 필요하다면 생성자, 함수 호출/정의시에도 유연하게 사용하여 가독성을 높임.
  • 단점 : 일관적이지 않고, trailing comma 사용에 대한 개인차가 생김
  1. Column Line Length의 제한을 아주 넓게 설정하고(300) 최대한 trailing comma 사용 하지 않도록 함.
  • 장점 : 코드가 대부분 한 줄 단위로 작성되므로 넓은 모니터에서는 코드 읽기가 조금 수월함.
  • 단점 : Dart에서 Column Line Length의 제한을 80으로 제한을 둔 이유가 있을거라 생각했고, 어느 정도의 길이는 괜찮으나 코드가 너무 길어지면 되레어 가독성이 떨어질거라 판단됨.

3번을 1차적으로 제외, 1/2 번 사이에서 고민중입니다.
일관성 측면에서는 1번이 좋다고 생각하고 있고, Line Length 80 제한을 바탕으로한 약간의 융통성을 발휘한 2번도 나름 나쁘지 않다는 생각입니다.

영빈님 팀에서 사용하시는 실무적 스탠다드는 어떤 방향일지 너무 궁금합니다.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저희는
1번을 전제로 하되, 아래 쪽 코멘트처럼 파리미터 명이 없을 경우는 comma를 생략하고 있습니다.

line length를 활용할 경우는 단점이 모든 팀원이 같이 설정을 맞춰야 하는데요. 이 부분이 git으로 관리가 좀 어려운 점이 있는 것 같아요.
그리고 모티러를 이용하는 경우도 있고 노트북 화면만 이용하는 케이스들도 있어서요. 하지만 기본 80은 요즘 모니터 크기에 비해 너무 짧다는 판단에 line length는 120으로 지정해서 이용하고 있습니다.

),
'${NumberUtil.formatByDefaultCurrency(_toBePaidPrice)}원 '
'배달 주문하기',
style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이쪽도 의견이 궁금합니다.

저의 경우 parameter가 있을 경우는 comma를 붙이고, 그 외는 안붙이는걸로 컨벤션을 정한 적도 있어요

예)

Widget(
  parameter: 123,
)

Widget(123);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이렇게는 생각해보지 못한것 같습니다. 😅

@ybin0823 ybin0823 self-requested a review August 26, 2022 11:12
Copy link
Collaborator

@ybin0823 ybin0823 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[lib]
  |_ [cart]
     |_ cart_screen.dart
     |_ [widget]
          |_ widget.dart

디렉토리도 깔끔하게 나누시고, 커밋도 잘 작성해주셔서 리뷰하기 편했습니다.
작성하시다가
이 class는 public보다는 private으로 작성하고 싶은데
파일을 나누면 접근이 안되니 좀 아쉬웠던 부분은 없으셨을까요?

그럴 경우 dart에서는

// cart_screen.dart
part 'widget/widgets.dart'
//widget/widget.dart
part of '../cart_screen.dart'

를 이용하면 물리적으로 파일을 나눌 수 있어요.

screen 코드가 짧을 경우는 1개 파일 내에서 private class로 선언하는게 오히려 이 class는 여기서만 사용한다는게 의도가 명확해서 좋지만
너무 길어질 경우는 파일을 분리하는게 좋거든요
그런데 파일을 분리했는데, 어쩔 수 없이 public으로 사용해야해서 아쉽거든요.
그럴 때 이용하면 파일도 나눌 수 있고 private로도 선언할 수 있어서 유용합니다.

주의할 점은 part of ''; 경로를 꼭 uri형식으로 지정해줘서 얘가 어디에 소속인지 명확하게 표현해주는게 좋습니다.

참고 : https://dart.dev/guides/language/effective-dart/usage#do-use-strings-in-part-of-directives

모든 파일을 바꿔보지 마시고 얘는 priavate이 낫겠다 하는 widget 1개 정도에만 사용해보시겠어요?

@devsoupe
Copy link
Author

part와 part-of를 이런 경우에 사용해야 되는거군요. 감사합니다!

@ybin0823 ybin0823 self-requested a review August 28, 2022 04:17
Copy link
Collaborator

@ybin0823 ybin0823 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

고생하셨습니다 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants