Format generated Go code to adhere to golang coding standards

[firefart]

Golang expects generated code to be properly go fmt'ed (see golang/go#73181 (comment)).

This PR tries to implement the changes so the code will be compatible and go fmt will not change anything in the generated code.

Changes:

• indent using tabs instead of spaces
• when there is only one return argument, omit the parentheses
• removes trailing spaces on comments without a content
• fix import ordering
• correctly indent case statements inside a switch

Test:
To test we will create a test client. Next go to the golangtest directory, init a git repo, and run go fmt to see the differences

rm -rf ./golangtest/ && cp -r ./it/go golangtest && dotnet build && ./src/kiota/bin/Debug/net9.0/kiota generate --openapi https://aka.ms/graph/v1.0/openapi.yaml --output ./golangtest/client --language go --exclude-backward-compatible --clean-output -i '/groups/getByIds#POST' -n 'integrationtest/client'
cd golangtest
git init
git add .
go fmt ./...
git diff

Ideally the git diff will show no changes

Still to do

• trailing spaces on setter methods
• some missing spaces between declarations

[baywet]

Thanks for the contribution!

[firefart]

The first version is ready for review @baywet . There are still some minor issues which I was not able to fix as I did not find the code that generates the corresponding code. I will open an issue with the additional minor issues that need to be adressed

[baywet]

@firefart thanks for the extended work on this. As for your question, have you looked here?

kiota/src/Kiota.Builder/Writers/Go/CodePropertyWriter.cs

Line 31 in e23ac20

writer.WriteLine($"{propertyName} {returnType}{suffix}");

It seems to me that if both the suffix and the return type are null or empty, we should not add the space.

[firefart]

@firefart thanks for the extended work on this. As for your question, have you looked here?

kiota/src/Kiota.Builder/Writers/Go/CodePropertyWriter.cs

Line 31 in e23ac20

writer.WriteLine($"{propertyName} {returnType}{suffix}");

It seems to me that if both the suffix and the return type are null or empty, we should not add the space.

@baywet thanks for the hint but this particular place it not the provblem. Added some checks, but the trailing spaces are still generated, so it must be elsewhere (but I suspect the same pattern)

[baywet]

Thank you for the additional information.

First, I'm not seeing the trailing space behaviour from the main branch.
Second, I spent more time looking into this, and it's actually here.

kiota/src/Kiota.Builder/Writers/Go/CodeMethodWriter.cs

Line 476 in 3491bb7

writer.WriteLine($"{funcPrefix}{associatedTypePrefix}{methodName}({parameters})({finalReturnType}{errorDeclaration}){openingBracket}");

Which breaks with the following conditional breakpoint.

code.IsOfKind(CodeMethodKind.Setter) && code.Parent is CodeInterface

Let me know if you have any additional comments or questions.

[firefart]

@baywet thanks, that did the trick, the trailing whitespaces are now gone. I also tried to add an integration test to github actions to run go fmt ./... on the generated code and error out if there are formatted files. Could you please approve the github actions run so I can check if the test works? (running it locally is not really possible)

[baywet]

Thanks for the continuous work on this one. One minor comment left

[baywet]

Thank you for making the changes!

[firefart]

@baywet fixed the unit tests, so would appreciate a new approval for all the tests.

PS: The used xunit version is really old, you should consider upgrading to xunit.v3. I needed to upgrade the local csproj files to this version so see the full strings from the Assert calls which is not possible in the current used version (I used XUNIT_PRINT_MAX_STRING_LENGTH=99999 dotnet test to test)

[baywet]

I'm not sure this change is correct, the request executor by definition makes the request, so might encounter a whole range of different errors which need to be reported back to the user. Even if the expected response doesn't have content.

[baywet]

The used xunit version is really old, you should consider upgrading to xunit.v3

Thanks for bringing this up. From reading the migration documentation, it seems there might be quite some work for this migration. If this is something you feel like you would like to submit a pull request for, I'd suggest starting a new issue.

[baywet]

gentle reminder on this one @firefart

[firefart]

@baywet sorry haven't found time yet to look into the tests, but hopefully by the end of the week to get this PR done