Godot: GDScript의 주석

사용자 정의 주석을 올바르게 이해하고 있으므로 다음과 같이 할 수 있습니다.

<strong i="6">@description</strong> "Adds two numbers and returns the result."
<strong i="7">@parameter</strong> name=num1 type=float description="The first number"
<strong i="8">@parameter</strong> name=num2 type=float description="The second number"
<strong i="9">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

그리고 get_annotations("add") 와 같은 함수를 호출할 수 있습니다. 이 주석은 이러한 주석을 반환합니까? 이러한 주석이 Godot에서 일부 내장 키워드/주석으로 인식되지 않더라도?

@LikeLakers2 네, 그게 요지입니다.

나는 그것을 좋아합니다. 뒤에 있는 구현에 대해서는 모르지만 GDscript 코드에서는 지금 보이는 것보다 훨씬 깨끗해 보일 것입니다. 특히 setget 예제의 경우.

이것은 매우 유용하지만 가독성을 위해 한 줄짜리 문장을 허용해야 합니다. 예를 들어,
<strong i="6">@onready</strong> var a = $A 는 허용되어야 합니다. 그렇지 않으면 많은 줄 바꿈이 추가되고 이 경우 onready의 유용성이 낭비됩니다.

같은 것

<strong i="10">@onready</strong>
    var a = $A
    var b = $B
    var c = $C

여러 명령문에 동일한 주석을 적용하는 데 유용합니다.

또한 콜론을 사용하여 주석이 끝나는 위치와 영향을 받는 명령문이 시작되는 위치를 표시하여 GDScript의 나머지 부분과 일관성을 유지할 수 있습니다.

주석이 명확한 시작과 끝으로 구문 분석될 수 있으면 세미콜론이 필요하지 않으며 필요한 경우 같은 줄에 넣을 수 있습니다(예: '()'를 사용하거나 인수가 없는 경우).

vnen이 오래된 바로 가기 키워드를 제거하려는 의도가 아니라고 생각합니까?

또한 형광펜을 사용하면 도움이 될 수 있습니다.

파티에 늦었지만 이것이 내보내기 변수에 대한 범주를 제공하고 도구/디버그 스크립트 분할을 생성하는 방법에 매우 관심이 있으십니까?

잠정적으로 3.2 로드맵을 작성하는 중인데, 에디터의 사용성 향상을 제공하기 위해 이 기능이 하루 빨리 구현되기를 진심으로 바랍니다.

#### 인기 없는 의견 수신:

gdscript의 구문이 왜 그렇게 많이 수정되고 있습니까? 원래 간단하고 배우기 쉽고 직관적으로 설계되었습니다. 나는 이러한 모든 새로운 추가 사항(입력된 gds, 주석)으로 인해 새로운 개발자에게 매우 혼란스러워질까 두렵습니다. 예를 들어, Godot의 새로운 사람이 튜토리얼을 보고 LikeLakers2의 게시물에 있는 코드를 본다면 머리가 터질 것 같습니다. 무엇이든 그들은 그것에 대해 / 그것이 어떻게 작동하는지 등에 대해 많은 질문을 해야 할 것입니다.

나는 gds에 대한 모든 사람의 사랑과 기여자들이 어떻게 더 나은 게임을 만들고 싶어하는지 등을 완전히 이해합니다. 저는 실제 게임 개발자와 기여자 사이에 가능한 단절이 있을 수 있다고 생각합니다(기여자가 게임 개발자가 아니라고 말하는 것이 아니라 단지 일부 기능은 실제로 필요하지 않습니다). 모든 사람이 이러한 기능을 사용할 필요는 없습니다. 나는 단지 gds가 그 단순함에서 점점 더 멀어질까 두렵습니다. 그게 전부입니다. 그것은 충분히보다 이미 더 ...

또한 export 키워드에 대해 3줄을 지정하는 것은 한 줄에 모든 것을 지정하는 것에 비해 매우 번거롭습니다. 예: onready var my_sprite = $Sprite 는 훨씬 더 깨끗합니다(어쨌든 나에게)

포인트 #4와 관련하여 AFAIK 편집기에서 이 작업을 수행할 수 있습니다. 또한 '특정 경고를 비활성화'하는 주석이 코드 곳곳에 있으면 코드가 매우 지저분해질 수 있습니다.

gdscript의 구문이 왜 그렇게 많이 수정되고 있습니까? 원래 간단하고 배우기 쉽고 직관적으로 설계되었습니다. 나는 이러한 모든 새로운 추가 사항(입력된 gds, 주석)으로 인해 새로운 개발자에게 매우 혼란스러워질까 두렵습니다.

전부는 아니지만 대부분의 GDScript 구문 변경은 이전 코드와 호환됩니다. 주요 목표는 GDScript를 사용하여 개발자의 생산성을 높이는 것입니다. 예:

• match 문은 switch-case 문(많은 요청이 있었음)을 허용하고 사람들이 배열과 사전을 쉽게 일치시킬 수 있도록 하여 이를 개선합니다.
• onready 변수(2.x의 새로운 기능)는 자주 사용되는 패턴, 즉 _ready 에서 변수를 초기화하는 패턴을 구체화합니다.
• Typed GDScript를 사용하면 개발자가 마침내 잘못된 유형의 오류가 발생하지 않는다는 것을 알게 되며 동시에 더 나은 자동 완성의 이점을 누릴 수 있습니다. 선택 사항이므로 신규 사용자는 첫 게임에서 이를 배울 필요가 없습니다.

실제 게임 개발자와 기여자 사이에 단절이 있을 수 있다고 생각합니다.

오픈 커뮤니티입니다. 게임 개발자는 여러분과 마찬가지로 와서 자신의 의견을 표현할 수 있습니다. 어쨌든 주석이 현실화되기까지는 상당한 시간이 걸릴 것입니다.

[...] 나는 gds가 그 단순함에서 점점 더 멀어질까 두렵습니다. 그게 전부입니다. 이미 충분하다...

이미 충분했다면 기능 요청을 받지 않았을 것입니다.

또한 export 키워드에 대해 3줄을 지정하는 것은 한 줄에 모든 것을 지정하는 것에 비해 매우 번거롭습니다. 예: onready var my_sprite = $Sprite가 훨씬 더 깔끔합니다.

구문은 아직 완료되지 않았습니다. onready 및 export 키워드를 즉시 대체하지 않을 가능성이 높습니다.

저는 C#의 속성과 같은 아이디어를 정말 좋아합니다.

클래스 및 신호 주석도 흥미로울 수 있습니다.

속성, 메서드 또는 클래스에 특정 사용자 지정 주석이 있는지 여부에 관계없이 자동으로 작동하는 Inspector 플러그인은 간단합니다.
구문에 관해서는 선택적으로 한 줄에 작성할 수 있는 것을 선호하지만 그렇게 중요하지는 않습니다.

사용자 정의 주석을 정의하는 프로세스는 어떻습니까? 나는 그것들이 코드에서 매번 자유롭게 정의되지 않고 클래스와 같이 단일 정의로 사용자에 의해 생성되는 것을 선호합니다.

나는 이것이 더 많은 조사가 필요하다고 생각합니다. 언어에 (선택적 구문 등으로) 추가하여 완전한 초보자가 뛰어들려고 하는 것을 혼동하지 않도록 하는 것이 좋습니다.

다음 구문을 보면 괜찮을 것 같습니다.

<strong i="7">@export</strong> type=String, hint=MULTILINE

"매개변수" 사이에 쉼표를 추가하면 다음과 같이 현재 구문과 좀 더 일관성이 있게 될 것이라고 생각합니다.

export (String, MULTILINE) var my_var

첫 번째 버전은 좀 더 장황하지만 더 명확하게 만들고 자동 완성 기능을 사용하면 너무 아프지 않아야 한다고 생각합니다. :)

앞으로 더 많은 구문 논의가 이루어져야 합니다. 전반적으로 아이디어가 마음에 듭니다.

주석은 구성 주입의 좋은 방법입니다. 그러나 구성과 코드를 분리하는 것이 더 깨끗한 접근 방식일 수 있습니다. 헤더 파일로 추가하는 것이 더 도움이 될 수 있습니다.

@bojidar-bg의 댓글에서...

어쨌든 주석이 현실화되기까지는 상당한 시간이 걸릴 것입니다.

누군가 이 구현을 지연시키는 "차단" 문제가 무엇인지 설명할 수 있습니까? GDScript/manpower에 대한 친숙함입니까, 아니면 주석을 지원하기 위해 미리 구현해야 하는 특정 기능이 있습니까?

글쎄요, 제 댓글 이후로 꽤 시간이 흘렀는데, 이미 증명된 것 같은데요?

주석 지원을 위한 주요 차단기는 핵심 개발자가 구문 및 의미 체계에 동의하도록 하는 것입니다. 그 후에는 구현이 비교적 쉬워야 합니다.

@reduz 는 주석이 메타데이터만을 위한 것이며 스크립트나 편집기 동작에 영향을 미치지 않아야 한다고 선호하기 때문에 이에 대해 논의해야 합니다. 이것은 나의 원래 제안을 아주 무의미하게 만들 것입니다.

특히 단일 키워드( onready , master , puppet 등)를 교체할 때 주석이 충분히 명확하다고 생각합니다. 그러나 우리는 여전히 합의에 도달해야 합니다.

설명된 대로 이것이 GDScript에 환상적인 추가 기능이 될 것이라고 생각합니다. 메타데이터에 국한되어서는 안 된다고 생각합니다. 변수에 사용되는 많은 키워드를 확실히 추월해야 합니다. 특히 export 는 어떤 경우에는 읽기가 조금 어려울 수 있습니다. 여러 문장으로 나누는 것이 이해에 도움이 된다고 생각합니다.

3년 된 문제 #6204를 우아한 방식으로 해결하는 데에도 사용할 수 있습니다.

<strong i="8">@export</strong>
<strong i="9">@export_tooltip</strong> "The name used when displaying this item in the inventory and in shops."
var display_name := ""

또한 메타데이터 이상을 지원해야 한다는 데 동의합니다. 그것은 많은 논리를 단순화하고 가독성을 향상시킵니다.

나는 @willnationsdev에 동의하고 주석을 사용하여 코드로 신호를 연결하고 싶습니다. 다음과 같이 코드 가독성을 향상시킬 수 있습니다.

@connect("timeout")
func _on_Timer_timeout():
   ...

@rluders 는 스크립트가 Timer 노드에 있다고 가정합니다.

@Zylann 물론입니다. 간단한 예입니다. "대상" 매개변수를 지원하고 자체 연결을 위해 생략할 수 있습니다. 예를 들어 스크립트가 Timer 외부에서 실행 중인 경우:

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

나는 이것이 어떻게 구현될 수 있는지 전혀 모르지만, 특히 키워드에 대한 gds의 주석을 보고 싶습니다. 그리고 기록을 위해 세미콜론이나 줄 바꿈 대신 '()'를 사용하여 주석을 구분하는 것이 좋습니다.

자체 주석 + 완전한 주석 프로세서를 만들 수 있다면 훨씬 더 좋을 것입니다.

@Zylann 물론입니다. 간단한 예입니다. "대상" 매개변수를 지원하고 자체 연결을 위해 생략할 수 있습니다. 예를 들어 스크립트가 Timer 외부에서 실행 중인 경우:

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

그것은 어떤 식으로든 플러그인에 의해 지원될 수 있지만, 나는 그것을 핵심 기능으로 만들지 않을 것입니다.
플러그인은 더욱 강력해질 수 있습니다.

내가 말할 수 있는 것은 이러한 것들이 구현되기 전에 gdscript를 배운 것이 기쁘다는 것뿐입니다.

@export_hint(ENUM)
@export_hint_string("Attack,Defense")
export var my_enum : int = 0

초보자인 나를 위해 구문 분석하는 것은 매우 벅차고 어려웠을 것입니다.

@sleepcircle 모든 경우에 GDScript를 단순하게 유지하려고 노력할 것입니다. 따라서 여기에서 비꼬는 말을 할 필요가 없습니다. 인용한 코드는 단지 제안일 뿐이며 _the_ 미래 구문이 아닙니다.

미안해요, 비꼬려고 한 건 아니에요. 나는 단지 대다수가 이러한 추가를 승인하는 것 같았기 때문에 그것들이 불가피하다고 가정했을 뿐입니다.

게임 개발자 강사로 내 $0.02를 던지고 싶었습니다. 경고: 별로 도움이 되지 않는 불필요하게 긴 설명은 새로운 개발자가 이를 어떻게 인식할 것인지에 대해 5년 동안 프로그래밍을 가르친 경험일 뿐입니다.

주석과 같은 새로운 언어 관용구를 만들 때 가능한 모든 어포던스를 피기백해야 하는 것이 중요하다고 생각합니다. 예를 들어 connect 를 사용하면 매개변수를 사용하고 일부 부작용이 있는 함수 를

@ 가 메타데이터에만 사용된 경우 새 개발자는 @ 볼 때마다 코드 논리에 영향을 주지 않는 메타데이터로 인식합니다. 논리에 영향을 미치는 경우 x 로 사용되기도 하고 y 로 사용되기도 하는 새로운 관용구를 추가하지 않는 것이 중요합니다.

현재 변수를 수정하기 위해 var 접두사, 접미사 및 대안이 있습니다. 반드시 "변수 수정자"가 아닌 몇 가지를 나열할 것이지만 새로운 개발자는 이러한 방식으로 볼 수 있습니다.

• 접두사: onready , export(...)
  
  
  
  • 이들은 각각 다른 유형의 행동을 가지고 있습니다. onready 는 런타임 변수 로딩에 영향을 미치고 export 는 일종의 편집기 힌트/메타데이터입니다. 그것들을 같은 장소에서 사용하는 것은 그들의 행동이 실제로는 그렇지 않을 때 어떻게든 연결되어야 하는 것처럼 느껴집니다.
  
  
• 대안: class_name , extends , signal , enum , const , func
  
  
  
  • 이러한 대체 형식은 괜찮지만 "enum" 및 "const"를 int 또는 string과 구별하는 것은 이상한 선택처럼 보입니다.
  
  
• 접미사: setget
  
  
  
  • 자체 범주의 Setget은 괜찮지만 개발자를 위한 설탕 키워드에 가깝고 로직 전환이 많지 않다는 점에서 export 와 유사합니다. 여기서도 생각이 다른 사람들을 볼 수 있지만
  
  
• 중간 위치: var x : int = 5
  
  
  
  • 특히 "enum"과 "const"가 동일한 것을 나타내기 위해 var에 대한 대체 키워드인 경우 이 사이에 입력하는 것이 이상하게 느껴집니다. 확실히 const 는 게임 로직 자체를 위한 도구라기보다 개발자의 경험을 수정한다는 점에서 setget과 유사합니다.
  
  

이제 주석 추가에 대해 살펴보겠습니다.

주석은 새로운 개발자에게 가르쳐야 하는 완전히 새로운 개념/관용구 일 것입니다. 이상적으로, 새로운 개발자는 새로운 관용구가 유용해지면 유기적으로 선택할 수 있도록 속도를 높이고 가능한 한 적은 관용구를 알 수 있어야 합니다. 테크트리라고 생각하시면 됩니다.

• (Tier 1) func, var 및 함수 호출, 조건문 및 루프와 같은 몇 가지 기본 프로그래밍 개념만 알면 게임을 만들 수 있습니다.
• (Tier 2) 그런 다음 신호, const, enum과 같은 유용한 설탕/기능을 배우기 위해 계속 이동합니다.
• (Tier 3) setget, onready와 같은 단축키를 배웁니다.
• (Tier 3.1) 게임을 바꾸지는 않지만 내보내기, 편집기 설명, 도구 및 입력과 같은 프로세스를 변경하는 개발자 전용 설탕을 배웁니다.
• (Tier 4) 순전히 문서화 및 프로젝트 구조

Tier 3-4가 주석의 주요 대상인 것 같습니다. 두 가지 다른 구현에 대해 학생들에게 두 가지 엘리베이터 피치가 있습니다.

• 순수한 메타데이터: "문서화 및 협업을 지원하려면 스크립트에 일부 메타데이터를 추가하는 주석에 대해 알아보세요. 주석을 사용하는 것보다 더 강력합니다."
• Dev 속기/설탕: "코드를 줄이거나 가독성을 높이려면 주석을 살펴보세요. 주석을 사용하면 일부 편집기 도구와 단축키를 제공하면서 변수와 기능을 설명할 수 있습니다."

나는 DEVS 고도 (Godot)의 숫자를 가르쳤다, 나는 주석 적어도 등급 3 옵션을 생각하고, 대부분에 차라리이없는 것 티어 4는 그들에게 보여 @ 이미 때까지 기호 전체적으로 합리적으로 복잡한 게임을 구축하고 프로세스 를 개선하려고

이것은 사람들에게 "문서가 필요한 더 큰 프로젝트를 빌드할 때 주석을 배우십시오"라고 말하기 쉽기 때문에 게임 기능에 중요하지 않거나 대체 구현이 있거나 순전히 문서화를 위한 개발자 속기 전용 주석을 사용하는 것이 제 의견임을 의미합니다.

스레드의 특정 포인트:

• 수출은 어떤 게임에도 중요하지 않기 때문에 수출에 문제가 없어야 합니다.
• Onready는 초기에 편리한 지름길이지만 새로운 개발자가 _ready 에서 시작하여 시작할 수 있고 주석이 중첩될 가능성은 onready 쓰는 횟수가 훨씬 적기 때문에 필요하지 않습니다.
• setget은 이미 너무 이상한 구문이며 이미 유일한 접미사로 자체 관용구입니다. 완전히 거기에있을 수 있습니다.
• Connect: 앞서 말했듯이 함수 호출 관용구에는 이미 완벽합니다. 여러 가지 연결 방법이 있으면 자습서/샘플 코드 공간이 혼동될 수 있습니다. 아마도 사람들이 자신의 주석을 작성하도록 허용하는 것이 이것을 표준화하는 것보다 나을 것이므로 비공개 프로젝트에서 작업하는 개발자가 반드시 공개 공간을 통합하지 않는 주석 라이브러리를 구축할 수 있습니다.
• 유형: 유형은 현재 일부 유형 수정자가 대안이고 일부 유형 수정자가 중간에 있는 이상한 위치에 있습니다. 주석으로 사용하면 @type(const int) @type(enum) , 모두 개발자 지향 설탕으로 통합됩니다.

다시 말하지만, 큰 기여는 아니지만 주석 아래에 포함되어야 하는 기능에 대해 생각할 때 고려해야 할 음식입니다. 나는 그것들이 좋은 아이디어라고 생각하지만 그것들이 어디에 맞는지 정확히 불분명합니다. 길이에 대해 죄송합니다. 저는 항상 약간 장황합니다.

나는 이것을 싫어한다.
모든 필드, 속성 및 메서드에 대해 많은 주석을 갖고 싶지 않습니다.

나는 더 많은 키워드를 가지고 싶다

사람들이 수많은 키워드를 좋아하지 않는다면 그 중 일부를 제거할 수 있습니다.

export MyClass : Node2D # export replaces class_name, : replaces extends 

signal mySignal #signal is kept

group(MyHeader, "res://icon.png" )
export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

#others are kept

나는 원래 제안에 전적으로 동의합니다.

나는 위의 의견에 동의하지 않지만 장점이 단점보다 훨씬 큽니다.

@Shadowblitz16 다음과 같은 이유로 여기 사람들에게 이러한 제안 중 많은 부분이 혼란스럽습니다...

export MyClass : Node2D # export replaces class_name, : replaces extends

export , class_name , : 및 extends 각각은 4개의 완전히 별개의 데이터 포인트와 시스템을 구성합니다. 복구 불가능하게 다른 것에 영향을 미치지 않고 단순히 전환할 수는 없습니다.

• export 는 편집기 GUI를 빌드하기 위해 Inspector로 전송되는 생성된 PropertyInfo 개체를 구성합니다.
• class_name 는 스크립트를 ScriptServer에 전역 클래스로 등록합니다. 기술적으로 유형 시스템과 관련이 없습니다. 런타임이 아닌 구문 분석 시간에 스크립트의 전역 인스턴스를 생성하는 경우에만 GDScript의 "정적 유형 지정"의 일부입니다.
• : 는 선택적 유형 힌트에 사용됩니다. 사람들이 GDScript를 항상 정적으로 입력하도록 하거나 대체 유형 힌트 구문을 제안하지 않는 한 콜론 토큰의 용도를 변경할 방법이 없습니다.
• extends 는 상속된 클래스에 사용됩니다(알다시피). 이것은 다른 언어에서 매우 일반적인 구문이며 모든 문서와 자습서는 이미 이 방법을 따릅니다. 이것에서 벗어나 순전히 미용상의 이유로 더 많은 작업을 만들려는 강력한 동기는 없을 것입니다.

group(MyHeader, "res://icon.png")

이것이 무엇을 할 것인지 나에게는 분명하지 않습니다. 내 말은, 노드가 "MyHeader" 그룹에 추가될 것 같습니다(이는 의미가 있을 수 있음). 그러나 아이콘은 무엇을 위한 것입니까? 그룹에는 연결된 아이콘이 없습니다.

export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

앞서 언급했듯이 이러한 것들은 모두 동일한 시스템이 아니라 다른 시스템에 영향을 미칩니다. 또한 값의 유형이나 초기화가 유연하기를 원하는 경우가 있습니다. 예를 들어, 동적 GDScript에서 다음과 같이 할 수 있습니다.

onready export(NodePath) var the_node = get_node(the_node)

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

준비 알림 전에 데이터를 초기화하는 것은 의미가 없습니다. 스크립트는 Node 클래스가 아니라 Object 클래스와 연결됩니다. 스크립트 속성은 구성 중에 초기화됩니다. Node 클래스의 생성자에 도달하더라도 변경되지 않습니다. _ready() 알림은 인스턴스화 후 훨씬 나중에 발생합니다. 변수 초기화의 기본 타이밍이 객체와 노드 사이에 다르다는 것은 극도로 혼란스럽고 Godot를 배우고 사용하는 사람들에게 예측할 수 없는 많은 행동으로 이어질 것입니다.

나는 당신의 제안을 무시하려는 것이 아니라 사람들이 제안된 변경 사항에 대한 정당성을 보지 못하는 이유를 설명하기만 하면 됩니다.

@willnationsdev 알겠습니다.
주석과 추가 키워드를 모두 수행하는 것은 어떻습니까?
이 방법으로 사용자는 원하는 경우 주석을 사용하고 필드당 수십 개의 주석을 원하지 않는 경우 키워드를 사용할 수 있습니다.

편집: C#을 이렇게 결합할 수 있는 속성으로 기록해 두십시오.
[Attribute1(), Attribute2()]
그러나 이것이 줄 수를 줄이는 데 도움이 될 수 있지만 여전히 약간 추악합니다.

@Shadowblitz16 우리는 가능하면 일을 하는 단 하나의 분명한 방법을 선호합니다. 두 개의 다른 구문을 갖는 것은 그 목표에 반대될 것입니다.

@Calinou 사람들이 타협할 수 없다면 gdscript는 그대로 두어야 한다고 생각합니다.
1 - 불필요하게 하위 호환성을 깨뜨립니다.
2 - 더 큰 파일과 덜 읽기 쉬운 코드를 생성합니다.
3 - 사람들이 익숙하지 않은 새로운 시스템으로 강제 변경합니다.
4 - 사람들이 원하지 않는 시스템을 사용하도록 강요합니다.

1 - 불필요하게 하위 호환성을 깨뜨립니다.
2 - 더 큰 파일과 덜 읽기 쉬운 코드를 생성합니다.
3 - 사람들이 익숙하지 않은 새로운 시스템으로 강제 변경합니다.
4 - 사람들이 원하지 않는 시스템을 사용하도록 강요합니다.

솔직히 말해서 아주 나쁜 주장들이다. 이 4개 중 3개는 API의 큰 변경 사항에 내재되어 있으며, 그 중 첫 번째 항목은 한동안 이전 키워드 기반 시스템과의 호환성을 유지함으로써 해결할 수 있습니다(사용 중단 경고 포함).

_편집: 자동 변환 도구를 제공할 수도 있습니다._

2번 항목의 경우 주석이 파일에 더 많은 행을 포함할 수 있다는 사실에 모두가 동의할 것이라고 생각하지만, 여기에서 대부분의 사람들은 주석이 가독성이 떨어지는 코드를 생성한다는 사실에 동의하지 않습니다.

@groud 이것은 불필요한 것에 주석을 사용하고 있습니다.
1 - 왜 작동하는 것을 비추천해야 합니까?
2 - 필드를 보기 위해 5줄 아래로 스크롤해야 하는 경우 가독성이 떨어집니다.

• 내보내기는 기본적으로 편집기에 대한 공개 키워드입니다.
• onready는 기본적으로 스크립트가 실행되기 전의 var 선언입니다.

둘 다 주석으로 적합하지 않습니다.

멤버 정의는 내가 실제로 이것이 좋은 것을 볼 수 있는 유일한 것이며 이 경우 접을 수 있어야 합니다. 그렇지 않습니다.

@groud 이것은 불필요한 것에 주석을 사용하고 있습니다.

이 스레드에서 많은 사용 사례가 제시되었습니다. 문서화, 내성, 더 복잡한 플러그인 등... 키워드로 다룰 수 없는 주석에 대한 사용 사례가 많이 있습니다.

1 - 왜 작동하는 것을 비추천해야 합니까?

그런 일을 하는 데에는 충분한 이유가 있습니다. 더 깨끗한 API, 더 많은 유연성 등을 허용하기 위해 모든 기능이 발전해야 할 수 있습니다. 그리고 새 버전이 널리 사용되면 가능한 한 이전 버전과의 호환성을 제거하는 것이 좋습니다. 이는 확실히 유지 관리 비용이 들기 때문입니다.

2 - 필드를 보기 위해 5줄 아래로 스크롤해야 하는 경우 가독성이 떨어집니다.

과장할 필요가 없습니다. 그러한 제안을 논의하는 목적은 그러한 문제를 피할 수 있을 만큼 충분히 똑똑한 구문을 허용하는 것입니다. IMHO, 내보내기 힌트는 내보내기 주석에 대한 인수로 통합될 수 있습니다(내 생각에 명명된 인수 시스템이 있을 수 있다면). 이러한 상황에서 시스템은 이전보다 훨씬 적은 공간을 차지할 수 있습니다.

또한 필드와 동일한 줄에 주석이 있는 것을 상상할 수도 있습니다. 나는 이것이 문제를 일으킬 수 있다고 생각하지 않는다.

내보내기는 기본적으로 편집기에 대한 공개 키워드입니다.
onready는 기본적으로 스크립트가 실행되기 전의 var 선언입니다.
둘 다 주석으로 적합하지 않습니다.

주석의 용도에 대해 선입견이 있을 수 있습니다. 나는 이러한 사용 사례가 주석 시스템에 완벽하게 들어맞는다고 생각합니다(많은 사람들이 그렇게 하는 것처럼 보입니다). 그러나 실제로 각 상황은 케이스 바이 케이스로 논의되어야 한다고 생각합니다.

나는 "lines" 인수가 특히 좋다고 보지 않습니다. 주석이 한 줄에 여러 명령문(또는 "접두사" 형식)을 직접 허용하지 않더라도 ; 를 구분 기호로 사용할 수 있습니다.

<strong i="7">@onready</strong> var my_sprite = $Sprite
@onready; var my_sprite = $Sprite


@export_hint_string("Attack,Defense")
@export_hint(ENUM) export var my_enum : int = 0

@export_hint_string("Attack,Defense")
@export_hint(ENUM); export var my_enum : int = 0


<strong i="8">@export_hint_string</strong> "Attack,Defense";
<strong i="9">@export_hint</strong> ENUM export var my_enum : int = 0

<strong i="10">@export_hint_string</strong> "Attack,Defense"
<strong i="11">@export_hint</strong> ENUM; export var my_enum : int = 0


<strong i="12">@export</strong> type=String hint=MULTILINE; var my_text = ""

# more options

@export(type = String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE); var my_text = ""

@export(String, hint = MULTILINE) var my_text = ""

# I personally prefer this one (positional and named args supported, default/optional args too)
@export(String, MULTILINE) var my_text = ""
@export(String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE) var my_text = ""
@export(int, ENUM, "Attack,Defense") var my_enum:= 0

편집: 아, 너무 느렸습니다. @groud는 이미 lines 인수를 처리했습니다. 글쎄, 적어도 그 몇 가지 코드 예제는 이 스레드에 무언가를 추가했습니다.

그것은 당신의 사람들의 의견입니다.
나는 개인적으로 @가 못생겼다고 생각한다.

편집하다:
그렇다면 멤버 선언은 어떻게 작동할까요?
그렇게하는 것은 끔찍할 것입니다

<strong i="10">@description</strong> "Adds two numbers and returns the result."
<strong i="11">@parameter</strong> name=num1 type=float description="The first number"
<strong i="12">@parameter</strong> name=num2 type=float description="The second number"
<strong i="13">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

@description 의 시작 부분에서 func 의 시작 부분까지 축소될 수 없는 경우

나는 주석이 유형을 대체하기 위한 것이 아니라고 생각합니다(귀하의 예에서 볼 수 있듯이). 문서 주석을 원하지 않으면 강제로 사용하지 않습니다.

func add(num1: float, num2: float) -> float: return num1 + num2

이 혼란은 내가 아는 한 실제 유형을 사용할 수 없는 내보내기 힌트가 있는 이상적이지 않은 상황에서 비롯된 것 같습니다(그리고 놀랍게도 내보내기 힌트가 배열과 같은 일부 유형을 지원하는 제네릭 유형이 없다는 문제).

나는 개인적으로 @가 못생겼다고 생각한다.
그렇다면 멤버 선언은 어떻게 작동할까요?
그렇게하는 것은 끔찍할 것입니다

다른 언어에서 이 목적은 일반적으로 주석이 아닌 주석을 제공하며 일반적으로 제안된 것과 동등하거나 더 장황합니다. C 언어 계열(가장 인기 있는 언어)에서 @ 는 주석에 대해 매우 일반적입니다(예: Java, JavaScript, TypeScript, Scala 및 내가 읽은 Python에서도 참조).

TypeScript(문서의 유형은 필요하지 않으며 도구는 실제 유형을 사용할 수 있다고 생각합니다):

/** Adds two numbers and returns the result.
 * <strong i="16">@param</strong> num1 {float} The first number
 * <strong i="17">@param</strong> num2 {float} The second number
 * <strong i="18">@return</strong> {float} num1 and num2 added together
  **/
const add = (num1: number, num2: number): number => num1 + num2;

기능적인 풍미:

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number", type=float)
@parameter(num2, "The second number", type=float)
@returns("num1 and num2 added together", type=float)
func add(num1: float, num2: float) -> float:
    return num1 + num2

중복 유형 없이:

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number")
@parameter(num2, "The second number")
@returns("num1 and num2 added together")
func add(num1: float, num2: float) -> float:
    return num1 + num2

부모 없는 맛:

<strong i="28">@description</strong> "Adds two numbers and returns the result."
<strong i="29">@parameter</strong> num1 "The first number"
<strong i="30">@parameter</strong> num2 "The second number"
<strong i="31">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

나는 이 구문이 문서 주석에 가장 적합합니다. 문서가 아닌 주석의 경우 func와 같은 구문을 선호하기 때문에 문서화 목적으로 주석을 사용하는 것에 대해 확신하지 못합니다.

이전 예제에서 주석 이름을 사용했습니다. @parameter 는 다른 언어에서와 같이 단순히 @param 수 있고 @description 는 @desc , @descr 또는 @func .

GodoDoc 에서 TypeScript(JSDoc 및 Javadoc에 기반한 TypeDoc) 기반 구문을 사용하고 있으며 제 생각에는 꽤 잘 작동하는 것 같습니다.

## Same as [[bool_]], but `on_false`/`on_true` are functions.
## Only selected function will be called and its return value will be returned from `bool_lazy`.
## <strong i="44">@typeparam</strong> T {any} Return type
## <strong i="45">@param</strong> cond {bool} Condition
## <strong i="46">@param</strong> on_false {FuncLike<T>} Function to call and return its result when `cond` is `false`
## <strong i="47">@param</strong> on_true {FuncLike<T>} Function to call and return its result when `cond` is `true`
## <strong i="48">@return</strong> {T}
func bool_lazy_(cond: bool, on_false, on_true): return GGI.bool_lazy_(cond, on_false, on_true)
var bool_lazy = funcref(self, "bool_lazy_")

@description 의 시작 부분부터 func의 시작 부분까지 축소될 수 없다면

예, 일반적으로 접기 및 기본 접기에 대한 옵션은 편집기에 좋은 추가 기능이 될 것입니다(블록 유형에 따라 접기, 예를 들어 내부 클래스가 기본적으로 접히는 설정에서 활성화할 수 있음).

나는 주석을 앞이나 위에 두는 기능을 좋아합니다. @annotation(a, b) 가 좋기 때문에 매개변수가 지정되지 않은 경우 대괄호는 선택 사항입니다. export 와 onready 가 속성에서 매우 일반적이기 때문에 앞에 넣을 수 있으면 오늘의 키워드와 같은 쓰기 속도가 가능합니다.

그러나 사용법 면에서 나는 문서화도 싫어한다. 나는 프로그램에 영향을 미치는 주석(간접적일지라도)에 익숙하지만 문서는 주석과 같은 사용을 위해 양을 세 배로 늘리고 모든 곳에 표시되고 기능적 주석과 동일하게 강조 표시됩니다... 뭔가 적합하지 않습니다. 그 유비쿼터스. 기본적으로 저는 C#에서 볼 수 있는 것과 동일한 주석 사용법을 좋아합니다. 따라서 멤버 위에 작성해야 하는 주석이 훨씬 적습니다(일반적으로 매우 드뭅니다. 일부 예에서 볼 수 있듯이 모든 사람이 5줄을 작성해야 하는 것은 아닙니다) . 논쟁이 스크립트 문서를 지정하는 API가 없는 Godot에 관한 것이라면, 그것은 문제이며 주석 IMO만으로 해결될 수 없습니다. 적어도 선택적으로 사용할 수 있다고 생각하지만 이러한 방식으로 강제로 수행하고 싶지는 않습니다. 이는 전체 규모의 문서화에는 불편합니다. (게다가 스크립트는 GDScript일 뿐만 아니라 _get_property_list 사용하는 경우가 더 어색합니다.)

나는 Zylann의 말에 전적으로 동의한다고 생각합니다. 나는 개인적으로 키워드와 같은 내보내기(또는 준비 완료)에 대해 이러한 구문을 허용합니다.

# No parenthesis when there are no parameters
<strong i="6">@export</strong> var myvar
# With parenthesis for parameters
@export(ENUM, "Up,Down,Left,Right") var myvar2
# Being able to write the annoation on the line before
@export(ENUM, "Up,Down,Left,Right") 
var myvar2

문서 부분과 관련하여 구문을 훨씬 더 단순화합니다( @mnn 의 예를

<strong i="11">@description</strong> "Adds two numbers and returns the result."
<strong i="12">@parameter</strong> "The first number" # No need to name the args if they are ordered
<strong i="13">@parameter</strong> "The second number"
<strong i="14">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

그러나 문서를 다른 곳에서 작성할 수 있도록 다른 시스템을 개발하는 것이 필수 라는 데 동의합니다. json, XML 또는 첫 번째 파일에서 내가 말할 것입니다. 코드 내 문서는 모든 프로젝트에 적합하지 않으며 문서용으로 많은 주석을 추가하는 것은 성가시며 어떤 경우에는 코드를 읽기 어렵게 만들 수 있다는 데 동의합니다.

관련성 링크: godotengine/godot-proposals#177

파티에 꽤 늦었지만 플러그인을 개발하기 위해 메타데이터와 리플렉션에 크게 의존하는 개발자로서 저는 주석이 Godot에서 일이 되는 것을 보고 싶습니다.

내보내기 및 준비된 항목과 같은 일부 항목을 더 아름답게 만든다고 생각하지만 내 주요 주장은 주석을 최대한 활용할 수 있는 사용자 정의 플러그인에 대한 것입니다.

onready 키워드 및 제한 사항에 대해.

나는 대부분의 사람들이 초기에 노드 참조를 초기화하기 위해 onready 를 사용한다고 말하는 것이 안전하다고 생각합니다. _ready 종속적인 일부 장면을 인스턴스화할 때 null 를 참조하는 문제에 걸려 넘어질 수 있기 때문에 장기적으로 문제 없이는 가능하지 않을 수 있다는 점을 제외하고는 다음과 같습니다.

func explode():
    var bomb = preload("res://explosion.tscn").instance()
    # Oops, forgot to `add_child(bomb)` earlier
    bomb.fuse.wait_time = 5.0 # ERROR: fuse is `null`
    add_child(bomb)
    # ... because `fuse` is a $Timer node 
    # which is only initialized once added to the scene tree.

물론 fuse 설정을 시도하기 전에 인스턴스화된 장면을 add_child() 해야 하지만 장면이 장면 트리에 추가 되기 전에 다른 노드/오브젝트가 정확한 퓨즈 를 알아야 하는 경우에는 어떻게 될까요? ?

얼마 후 https://github.com/godotengine/godot/issues/33620#issuecomment -559999681에 설명된 대로 솔루션을 찾았습니다. 거기에서 알 수 있듯이 onready 는 단지 NOTIFICATION_READY 인 반면 실제로 필요한 것은 NOTIFICATION_INSTANCED 이었고 내 참조를 더 일찍 초기화했습니다. 유일한 문제는 oninstanced 키워드가 없다는 것입니다. 제가 무슨 말을 하는지 알 수 있을 것 같습니다. 🙂

따라서 onready 키워드를 주석으로 리메이크하는 동시에 스크립팅 언어를 부풀리지 않고 @oninstanced 기능을 사용하여 다른 일부 사례(예: 항상 그렇듯이!)도 지원하는 것이 좋을 것 같습니다. , 초기화와 관련된 기타 알림 지원 추가( _init , _enter_tree 등).

관련 제안: godotengine/godot-proposals#260.

더 구체적인 세부 정보가 포함된 제안서를 열었습니다: https://github.com/godotengine/godot-proposals/issues/828

위의 제안으로 대체됩니다.