rustics/dns
2
0
Fork 0
Code Issues 8 Pull Requests Projects 1 Releases Wiki Activity

Namen der RFC Felder (lang vs. kurz) #2

New Issue
Closed
opened 2022-03-16 20:24:07 +01:00 by ddidderr · 1 comment
ddidderr commented 2022-03-16 20:24:07 +01:00
Owner
Copy Link

Ich hab mal in das trust-dns Projekt reingeschaut, einfach nur wegen der Frage, wie benennen die die aus der RFC stammenden Felder.

Antwort:
Die machen lange und verständliche Namen.

Alle Struct Member sind private, aber sie haben für alles jeweils eine pub getter Funktion, allerdings ohne das extra get Präfix.

Interessant ist hier die Idee, einfach die passenden Teile der RFC in die Dokumentation zu packen, bspw. hier oder auch hier.

Davon abgesehen würde ich vorschlagen, da nicht viel weiter in den Quellcode zu schauen, da wir uns das ja selbst erarbeiten wollen. Ich wollte nur schauen, wie es mit den Membernamen so aussieht.

Die Frage ist nun:
Machen wir die Membernamen auch lang und verständlich anstatt kurz und dafür exakt wie in RFC?
Oder lassen wir sie kurz und bauen auf die Doku?

Ich hab mal in das `trust-dns` Projekt reingeschaut, einfach nur wegen der Frage, wie benennen die die aus der RFC stammenden Felder. Antwort: Die machen [lange und verständliche](https://github.com/bluejekyll/trust-dns/blob/dc5c414ec0553af8a65441d0c747fb8e9f8e174e/crates/proto/src/op/header.rs#L51) Namen. Alle Struct Member sind private, aber sie haben für alles jeweils eine `pub` getter Funktion, allerdings ohne das extra `get` Präfix. Interessant ist hier die Idee, einfach die passenden Teile der RFC in die Dokumentation zu packen, [bspw. hier](https://github.com/bluejekyll/trust-dns/blob/dc5c414ec0553af8a65441d0c747fb8e9f8e174e/crates/proto/src/op/header.rs#L176) oder [auch hier](https://github.com/bluejekyll/trust-dns/blob/dc5c414ec0553af8a65441d0c747fb8e9f8e174e/crates/proto/src/op/header.rs#L400). Davon abgesehen würde ich vorschlagen, da nicht viel weiter in den Quellcode zu schauen, da wir uns das ja selbst erarbeiten wollen. Ich wollte nur schauen, wie es mit den Membernamen so aussieht. Die Frage ist nun: Machen wir die Membernamen auch lang und verständlich anstatt kurz und dafür exakt wie in RFC? Oder lassen wir sie kurz und bauen auf die Doku?
ddidderr added the
question
 label 2022-03-16 20:24:07 +01:00
ddidderr self-assigned this 2022-03-16 20:24:07 +01:00
mice_on_drugs was assigned by ddidderr 2022-03-16 20:24:07 +01:00
ddidderr added this to the 0.1 sprint project 2022-03-17 20:49:09 +01:00
Maashkinoozhe was assigned by ddidderr 2022-03-23 08:37:34 +01:00
ddidderr commented 2022-04-03 18:24:57 +02:00
Author
Owner
Copy Link

Ich sehe es so, dass wir uns auf lange und verständliche Namen geeinigt haben jetzt.

Ich sehe es so, dass wir uns auf lange und verständliche Namen geeinigt haben jetzt.
👍 1 🚀 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
architecture
Discussions about how to solve a problem in code.
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
refactor
Refactor code
wontfix
This won't be fixed
No Label
question
Milestone
No items
No Milestone
Projects
Clear projects
No project 0.1 sprint
Assignees
Clear assignees
No Assignees ddidderr mice_on_drugs Maashkinoozhe
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rustics/dns#2
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?