Consistent naming for enterprise & organization scoped functions
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne damit, die im Issue besprochenen Funktionen mit Enterprise- und Organisations-Scope zu inventarisieren und ihre aktuellen Benennungsmuster zu überprüfen. Lege die Konventionen für gültige Scopes und Subjects fest, bevor du Namen änderst, und überprüfe anschließend, dass die resultierende API über alle betroffenen Funktionen hinweg konsistent angewendet wird.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
I'd like to see a consistent naming convention used for enterprise and organization scoped functions that reflects the significance of the scoping. My suggestion is that we adopt the pattern <VERB><SCOPE><SUBJECT> which as a very simple example would look something like GetOrganizationThing. Scope and subject are an overlapping concept so we will need to define valid scopes that are linear (possibly just enterprise and organization). Subject is a more of an art than a science but we will still want to keep the most significant information at the beginning of the function name.
As an example of an alternative but supporting pattern; in a greenfield API design these scopes could have been structural with a pattern such as client.organization.GetThing instead of client.GetOrganizationThing.
- Vorherrschende Sprache
- Go
- Sterne
- 11.3k
- Forks
- 2.6k
- Ø Merge
- 2 T. 2 Std.
- Gemergte PRs (30 T.)
- 34
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus google/go-github
-
Rate-limit retry replays a consumed request body for POST/PUT/PATCHEvtl. vergeben @AdamMagued hat das vor 4 Tagen übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 70/100
google/go-github#4656 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
otel: redact sensitive query parameters before recording http.urlEvtl. vergeben @sai5880 hat das vor 4 Tagen übernommen. Offen
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 55/100
Maintainer antworten meist innerhalb von 1 Tag
-
Error() methods modify the request URL of the response they wrapEvtl. vergeben @AdamMagued hat das vor 5 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 30/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 5/100
google/go-github#4636 · 11 Kommentare · 3 Reaktionen ·
Maintainer antworten meist innerhalb von 1 Tag
-
http.Client.Timeout is ignored by redirect-aware requestsEvtl. vergeben @sb123sb123 hat das vor 34 Tagen übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in google/go-github
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
blinklabs-io/dingo#5636 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
JetBrains/youtrack-cli#130 ·
Maintainer antworten meist innerhalb von 1 Tag
-
kind/bug needs-triage sig/release
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
kubernetes/kubernetes#143392 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 61/100
Maintainer antworten meist innerhalb von 1 Tag
-
stage-fail
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100
siyuan-note/bazaar#2405 ·
Maintainer antworten meist innerhalb von 1 Tag