codegen: applying kotlin naming rules to operationId param

[pedro-cze]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Refactoring
• Other... Please describe:

What is the current behavior?

Currently if operationId contains whitespaces the resulting function name is wrongly createad as foo bar(). This hould be prevented.

Fixes #30

What is the new behavior?

From now on the operationId will follow naming rules specified for kotlin functions. That means that the first character is removed in case it is a digit. After this check the Functions.toCamelCase() function is applied.

Does this PR introduce a breaking change?

• Yes
• No

Additional context

• none

[niraj8]

Thanks for the great first contribution! Please see my comment below.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication

[pedro-cze]

hi, @niraj8, can I ask you for a check and response if provided fix is sufficient and the PR can be merged pls.? Thanks.

[niraj8]

Hey @pedro-cze!
Been a bit occupied lately.

I went over the issue once again and I think we should take a different approach here.

Instead of converting operationId to conform to function names, we should fail while parsing and ask for valid operationId, with a helpful error message that mentions what is considered valid.

I can't think of any reason for an operationId to start with any non-alphabetic characters.

The operationId would then be mapped directly to the generated controller function for that operation, which was my intention when I suggested we prefix the function name with operation to maintain the original operationId in some way.

We should fail while parsing the spec yml if the operationId doesn't conform to the kotlin function as is.
Later we could allow an option, which bypasses this maybe.

What do you think?

[pedro-cze]

Hi @niraj8 and thanks for your reply :)
True is that I might be overthinking this but on the other hand the name generation depends on a .yml file that can theoretically contain anything. But I am ok with what you suggest. IMHO if the operationId doesn't conform the function name conventions, we can just return the HTTP method name as is already the case if no operation id is provided plus I can add some "log warn" to log that the provided name is invalid.

Is that ok?

Thanks.