Remove lateinit usage in Main.kt

[Mauin]

Resolves #132

This follows the recommendation from the issue. But overall I'm not sure if its nicer to have 3 !! in the code compared to the lateinit var.

Probably also the null check in validateCli is not really useful as the project parameter is already required = true and thus JCommander will already throw an exception if the parameter is not specified.

[arturbosch]

Yeah that is not pretty at all :), my other thought was to introduce a backing field so we do not need the !! everywhere?

[Mauin]

Yep, agree. I'll explore some other approaches later today. 👍

…

On Wed, Jul 5, 2017 at 9:59 AM Artur Bosch ***@***.***> wrote: Yeah that is not pretty at all :), my other thought was to introduce a backing field so we do not need the !! everywhere? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#156 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF4k0WGAcCeFTXA9q2Hr5-51DF-qxt0Rks5sK0JWgaJpZM4ON8ed> .

[Mauin]

As mentioned this is not really necessary as JCommander already requires this parameter to be set. Let me know how you feel about this one also being here.

[arturbosch]

Then delete this lines and do a test run with the CLI and we are happy :)

[Mauin]

Updated the PR by using the backing field and making project private to prefer using the non-nullable field. Looks better for me.

[MyDogTom]

I'm just curious why lateinit is a bad practice? Especially when it's replaced with !!. For me this change means that UninitializedPropertyAccessException will be just replaced with NullPointerException.

[arturbosch]

Because it misleads you not using a safer way to initialize a variable (constructor injection or delegation).

When I started programming in Kotlin I often used lateinit in spring-framework or just because I found using constructors in Kotlin difficult (always calling primary constructor in secondary constructors etc) and I think this is a common pitfall for newcomers.

Ofc in our case it seems kind of odd to replace one keyword with a backing field, but this due to the nature of many annotation heavy libraries (jcommander). Ofc if you know what you do lateinit is not that bad and in our solution we are also relying on jcommander to check the field, while the backing field looks unsafe ...

The tradeoff here is like Suppress annotation vs backing field :D