No-Op Implementation

[rtsketo]

Edit:

With this PR, two artifacts will be published, ktee and ktee-noop.
As the name suggests, ktee-noop has no internal functionality and it can be used in production environment with no overhead.

With this PR, the user can enable or disable logging and printing by setting KTee.debug variable true or false.

This can be automated depending your build, for example in Android the user can set the variable as KTee.debug = BuildConfig.DEBUG at the start of his app.

By default is set to true.

PS. I think this was suggested by someone in Reddit.

[kdabir]

Thanks for taking time to contribute. At present we are not in position to merge this request because of two reasons. 1. it used mutable variable 2. it does not include test cases.

[kdabir]

we actively avoid using var in our codebase. This becomes a global variable which is not good in server/multithreaded/concurrent envs.

[rtsketo]

I've made some changes. The variable can now be set only once.
If you are concerned about thread safety, @volatile can also be used instead.
Other than that, I fail to see how it's possible to have a toggle without being a var.

[rtsketo]

Fixed the second issue.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

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

No Coverage information
No Duplication information

[kdabir]

Can we look at alternative like a No-Op interface just like slf4j. That way dependency can be swapped at build/compile time without having to change code. in no-op impl all the methods essentially do not output anything. We can produce two artifacts ktee and ktee-noop?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[rtsketo]

@kdabir, coming from the "Android world" where build types and flavors are a thing in Gradle, I can't be so sure I implemented the No-Op artifact publication in the best way possible. Please, let me know if there's something that can be improved.

[kdabir]

apologies for the delay in responding. The changes are looking good. For no-op project, we could go with a multi-module approach rather than additional source set. However, I don't necessarily see problem with current approach too. Let me review this and provide more specific feedback. Thanks for incorporating the feedback.

[rtsketo]

Of course, I'm up for giving a try to any better solution. Could you please give me more info on how to approach a multi-module solution and what are the advantages compared to the current?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[rtsketo]

If someone is looking for this feature, I released a modified version here. Using a noop implementation in production does make reverse engineering slightly harder, thus I recommend it unconditionally in any non server-side code.