Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistency regarding if-initializers #17

Open
jnichols-git opened this issue Jul 24, 2022 · 0 comments
Open

Consistency regarding if-initializers #17

jnichols-git opened this issue Jul 24, 2022 · 0 comments
Labels
code quality Doesn't change functionality but improves code quality good first issue Good for newcomers

Comments

@jnichols-git
Copy link
Owner

Go allows for the initialization of variables before if statements. For example, if we have a function foo() (string, error), you could:

if resultString, err := foo(); err != nil {...} else {...}

Both resultString and err belong to the scope of the if/else statement here. This is a handy way to manage functions that return errors (almost all of them) but isn't generally used routinely due to scope; often if err is nil, you want to do something with resultString, but doing it in the else block is awkward, so instead code will usually read

resultString, err := foo()
if err != nil {...}
...

The project as it is now doesn't handle this consistently, so I'm setting a guideline and leaving it as an issue to be fixed:

  • IF all values returned by the function are specifically related to the handling of an error returned by that function, then an initializer should be used.
  • OTHERWISE, regular syntax should be used.

I will be digging around for this for the time being, but it's a good place to start if you're unfamiliar with Go and want to familiarize yourself with syntax.

@jnichols-git jnichols-git added good first issue Good for newcomers code quality Doesn't change functionality but improves code quality labels Jul 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code quality Doesn't change functionality but improves code quality good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant