Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Refactor codebase to use value parameters instead of pointers where appropriate

Abierto
#3,644 24 comentarios 4 reacciones 3 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@ManavSharma142 ya está trabajando en esto.

Desde el 5/8/2026.

  • #4320 de @JamBalaya56562 — fusionado

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Breaking API Change enhancement good first issue

Many methods in the codebase, such as:


func (s *RepositoriesService) CreateRelease(ctx context.Context, owner, repo string, release *RepositoryRelease) (*RepositoryRelease, *Response, error)

use pointer parameters (e.g. *RepositoryRelease) even when the function doesn't mutate the input. This appears to be a result of convention or copy-paste, not a performance-driven choice.

For instance, in CreateRelease, the RepositoryRelease struct is relatively large (~15+ fields), but most of its fields are pointers themselves. As such, passing it by value would have negligible performance impact in typical API usage. Moreover, value semantics would improve clarity, especially for required arguments that aren't modified.

To improve API design consistency and safety, we should:

  • Audit method signatures that accept pointer structs as input

  • Change them to accept values when:

    • The input is required (not optional)

    • The function does not modify the input

  • Optionally introduce dedicated input structs for specific operations (e.g. CreateRepositoryRelease with only the fields needed for creation)

Note: This would be a breaking change and should be handled carefully, possibly across multiple PRs.

Originally posted by @gmlewis in https://github.com/google/go-github/pull/3636#discussion_r2228429223

Lenguaje dominante
Go
Estrellas
11.3k
Forks
2.6k
Merge medio
2 d 19 h
PR fusionados (30 d)
36

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/go-github

Todos los issues de google/go-github

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.