UsedImplicitly속성으로 Unity 라이프 사이클 메소드에 주석을 달면 코드의 가독성이 향상됩니까?
예를 들면 다음과 같습니다.
public class Example : MonoBehaviour
{
[UsedImplicitly]
private void Awake()
{
DoSomething();
}
private void DoSomething()
{
// ...
}
}“Unity MonoBehaviours 구조화”에 대한 이 블로그 게시물 은 이러한 접근 방식을 유용한 규칙으로 제안합니다.
- [UsedImplicitly] 속성을 사용하여 코드에서 암시 적으로 (또는 자동으로) 호출되는 Unity 수명주기 메소드 (Start, Awake, Update, OnDestroy 등), 이벤트 메소드 및 기타 함수에 주석을 답니다. 이 속성은 UnityEngine.dll에 포함되어 있지만 ReSharper에서 참조되지 않은 것처럼 보이는 메서드에 대한 코드 정리 제안을 비활성화하는 데 사용됩니다. 또한 Unity 및 코드베이스를 처음 접하는 사람들, 특히 검사자를 통해 참조되는 이벤트의 경우 코드를보다 쉽게 읽을 수 있도록 도와줍니다.
(참고 : ReSharper는 참조되지 않은 Unity 라이프 사이클 방법에 대한 코드 정리 제안을 보여주지 않기 때문에 오래된 조언 일 수 있습니다.)
위의 게시물에 동의하면 Unity를 처음 접하는 사람들에게 도움이 될 수 있습니다. 또한 자주 사용하지 않는 Unity 라이프 사이클 함수Awake 에 Start, 및 로 자주 레이블을 지정하는 것이 유용 할 수 있다고 생각합니다 Update. 그러나 이것이 실제로 “깨끗한 코드”에 대한 좋은 규칙인지 또는 가독성을 줄이는 소음인지 궁금합니다.
답변
대상 인구 통계에 따라 다릅니다.
위의 예에서 대상 인구 통계는 ReSharper 도구로, 도움이되지 않는 메시지를 표시하지 않기 때문에 이러한 특성을 활용할 수 있습니다. 그러나 ReSharper 또는 이와 유사한 도구를 사용할 필요가 없다고 생각한다면 (때로는 유효한 비판이있을 수 있음) 해당 인구 통계에 신경 쓸 필요가 없습니다.
지금까지 기본적인 유니티 자습서를 한 사람은 아주 잘 것을 알고 Start그리고 Update그것이 그들에게 새로운 정보를 제공하지 않도록, 유니티 엔진에 의해 암시 적으로 사용됩니다. 당신이 이것을 한 번 잊어 버리면 실제로 그것들을 혼란스럽게 할 수도 있습니다. 그걸로 무엇을 말하고 싶습니까? 이것은 실제로 MonoBehaviour가 아닐까요? 아니면 내가 모르는 것을 명시 적으로 호출 해야하는 모호한 이유가 있습니까?
그러나보다 난해한 Unity 이벤트에 익숙하지 않은 경험이 부족한 개발자와 함께 작업하는 경우 도움이 될 수 있습니다 Reset. [UsedImplicitly]속성은 그 때 엔진 않기 때문에 그 메소드를 호출하는 클래스를 찾을 필요가 없습니다 그들에게 있습니다. 그러나 다시 말하지만, 이것이 일관되게이를 수행 할 수있는 원칙이있는 경우에만 가치가 있습니다. 그리고 당신이 그 정도의 자기 훈련을 가지고 있다면, 당신은 의견을 추가하는 것에 동의 할 수 있습니다.
답변
나는 당신이 그것을 사용해서는 안된다고 주장합니다.
UsedImplicitly 속성은 Jetbrains.Annotations 네임 스페이스의 속성이므로 코드를 사용하는 모든 사람이 ReSharper를 사용하는 경우에만 적용됩니다.
ReSharper에는 Unity 용 플러그인 이 이미 있습니다. 사용하지 않았다는 경고를 제거 할뿐만 아니라 작은 Unity 기호로 표시하여 코드를 읽는 사람이 Unity 자체에서 호출 한 것을 확인할 수 있습니다.
또한 사용할 때 예제를 추가하고 싶습니다. MonoBehaviour에서 상속받은 클래스가 있다고 가정하지만 리 팩터 후에는 더 이상 상속이 없습니다. [UsedImplicitly]로 개인용 메소드를 표시 한 경우 올바른 경고가 표시되지 않습니다. resharper에 Unity 플러그인을 사용하면 더 이상 MonoBehaviour에서 상속되지 않으며 메소드가 더 이상 호출되지 않으므로 경고가 표시됩니다.
답변
나는 그것이 정말로 아프지 않다는 주장을 할 것입니다.
Unity의 작업에 매우 익숙한 사람에게는 아마도 아무것도 추가하지 않을 것입니다. 그 사람들은 이미 Unity의 런타임이 귀하를 대신하여 호출하는 것에 대해 잘 알고 있습니다.
그러나 나와 같은 사람이 아닌 사람에게는 도움이 될 수 있습니다. 내가 무슨 뜻인지 알지 못하더라도 찾아 보면 코드에서 무슨 일이 있었는지 더 잘 이해할 수있을 것입니다.
또한 분석법에 대해 잘못 경고하는 정적 분석 도구를 사용하는 경우 “무시할 수있는”경고 잡음으로 인해 이러한 출력에서 실제 경고 를보기가 더 어려워 지므로 이러한 경고를 어떻게 멈출 수 있습니다 . 일반적으로 해당 경고를 프로젝트 전체에서 비활성화하는 것과 같은 광범위한 조치를 통하는 것보다 외과 적, 현지화 된 방식으로 (이 경우 문제가있는 방법을 속성으로 장식하여) 이러한 경고를 무시하는 것이 좋습니다.
답변
이 방법의 문제점은 오류가 발생하기 쉽다는 것입니다.
그것이 신뢰할 수 없다면, 태그는 유용한 정보를 전달하지 못하고, 그 유무는 때때로 잘못된 정보를 전달하는데 성공하는데, 이는 해로운 것입니다.
당신이 그것을 결정하기로 결정했다면 , 인간의 실수를 제거 해야합니다 . 이는 어렵지 않지만 이전에 이와 같이하지 않은 경우 2 시간의 작업이 필요합니다. 각각 고유 한 장점이있는 두 가지 접근 방식이 있습니다.
- 체크인 또는 자동 빌드시 비준수 코드 확인 및 거부
- 체크인 또는 자동화 된 빌드시 태그를 수정하기위한 자동 코드 편집
그것을 가질 가치가 있습니까? 예. 2 시간의 가치가 있습니까? 당신의 전화.