Hey, @liamnichols. I reviewed the new names and sharing a few thoughts. I don't have any strong feelings about these names though, so don't feel like you need to respond, but please consider updating some of these names.

• useIntegersWithPredefinedCapacity - these are called "fixed-width integers'
• stripParentNameInNestedObjects - this is probably safe to remove; it has mechanisms to ensure that it never (?) leads to ambiguity
• defaultValues - should it be a verb, e.g. add/use default values?
• includeInitializer - I'd probably use "generate" for this, or "addInitializers" but either way is good
• identifiableConformance - same as the previous
• generateStructs - I don't remember what it does anymore, but it seems like an enum would've probably been a better option. Otherwise it's not clear. For example, what if it's false? Will it just skip and not generate any structs?
• makeOptionalPatchParametersDoubleOptional - that's a mouthful, but it's not yet in its target state – using double-optionals is not ideal
• generateResponseHeaders - seems good, but inconsistent with other options, e.g. includeInitializer; they should probably use the same verb – "generate" sounds good (but not in "generateStructs")

Thanks @kean for the feedback!

• useIntegersWithPredefinedCapacity - these are called "fixed-width integers'

This is good to know, in that case I think useFixWidthIntegers seems more appropriate.

• stripParentNameInNestedObjects - this is probably safe to remove; it has mechanisms to ensure that it never (?) leads to ambiguity

Ok thanks, I'll take a look at it but will probably leave it for now as I'm still not too sure what it does exactly 😄

• defaultValues - should it be a verb, e.g. add/use default values?

Good point, maybe to align with the others includeDefaultValues

• includeInitializer - I'd probably use "generate" for this, or "addInitializers" but either way is good

heh yeah I was a little stuck on this. To be honest, I was trying not to use the term generate in any option but looking back it, I was a little inconsistent still 😄

I feel like generate is a bit repetitive because these are options for the generator hence going for a term like include instead. "Include the initialisers when generating entities" for example.

• identifiableConformance - same as the previous

Yeah this too could be includeIdentifiableConformance, I'll change it.

• generateStructs - I don't remember what it does anymore, but it seems like an enum would've probably been a better option. Otherwise it's not clear. For example, what if it's false? Will it just skip and not generate any structs?

In #100 we decided to do like you suggested and replace it with an type enum that is a bit more descriptive when it's false (type: struct, type: class or type: finalClass)

• makeOptionalPatchParametersDoubleOptional - that's a mouthful, but it's not yet in its target state – using double-optionals is not ideal

Heh yeah. I've actually left this one undocumented in ConfigOptions.md because I want us to revisit it (part of #18 maybe). I think its fine how it is for 0.1 but it will likely change again soon.

generateResponseHeaders - seems good, but inconsistent with other options, e.g. includeInitializer; they should probably use the same verb – "generate" sounds good (but not in "generateStructs")

I think also includeResponseHeaders might make sense here (see my reasoning for 'include' vs 'generate' above)