Skip to content

Conversation

mnoman09
Copy link
Contributor

@mnoman09 mnoman09 commented Jan 2, 2019

Summary

  • Nit fixes in entire java sdk code and added missing headers

@coveralls
Copy link

coveralls commented Jan 2, 2019

Pull Request Test Coverage Report for Build 822

  • 350 of 376 (93.09%) changed or added relevant lines in 48 files are covered.
  • 11 unchanged lines in 7 files lost coverage.
  • Overall coverage increased (+0.02%) to 89.788%

Changes Missing Coverage Covered Lines Changed/Added Lines %
core-api/src/main/java/com/optimizely/ab/bucketing/DecisionService.java 8 9 88.89%
core-api/src/main/java/com/optimizely/ab/bucketing/UserProfileUtils.java 0 1 0.0%
core-api/src/main/java/com/optimizely/ab/config/ProjectConfig.java 19 20 95.0%
core-api/src/main/java/com/optimizely/ab/config/parser/GsonHelpers.java 11 12 91.67%
core-api/src/main/java/com/optimizely/ab/event/LogEvent.java 0 1 0.0%
core-api/src/main/java/com/optimizely/ab/event/internal/payload/Snapshot.java 3 4 75.0%
core-api/src/main/java/com/optimizely/ab/internal/EventTagUtils.java 2 3 66.67%
core-api/src/main/java/com/optimizely/ab/internal/ExperimentUtils.java 0 1 0.0%
core-api/src/main/java/com/optimizely/ab/OptimizelyRuntimeException.java 0 2 0.0%
core-api/src/main/java/com/optimizely/ab/config/audience/UserAttribute.java 0 2 0.0%
Files with Coverage Reduction New Missed Lines %
core-api/src/main/java/com/optimizely/ab/Optimizely.java 1 93.31%
core-api/src/main/java/com/optimizely/ab/bucketing/DecisionService.java 1 93.13%
core-api/src/main/java/com/optimizely/ab/config/audience/UserAttribute.java 1 84.21%
core-api/src/main/java/com/optimizely/ab/config/parser/GsonHelpers.java 1 96.1%
core-api/src/main/java/com/optimizely/ab/config/ProjectConfig.java 2 97.66%
core-httpclient-impl/src/main/java/com/optimizely/ab/event/AsyncEventHandler.java 2 56.41%
core-api/src/main/java/com/optimizely/ab/internal/ConditionUtils.java 3 83.33%
Totals Coverage Status
Change from base Build 821: 0.02%
Covered Lines: 2708
Relevant Lines: 3016

💛 - Coveralls

Copy link
Contributor

@mikeproeng37 mikeproeng37 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, I just have one small comment

* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the missing header!

@loganlinn loganlinn self-requested a review January 2, 2019 20:11
Copy link
Contributor

@loganlinn loganlinn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the much needed clean-up. I left a few comments where I think we can do a little better while we are in here making changes.

Main thing we should clean-up is the placement of annotations on return types. I added a handful comments on specific lines, but not exhaustive. Can find more by searching the diff for "public @"

@@ -117,7 +118,8 @@ public LiveVariable(@JsonProperty("id") String id,
this.type = type;
}

public @Nullable VariableStatus getStatus() {
public @Nullable
VariableStatus getStatus() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be single line.

the cause is probably the annotation on the return type being unconventional. Snippet below is equivalent and probably wont confuse auto-formatter tool

     @Nullable
     public VariableStatus getStatus() {

* @param errorHandler the error handler to send exceptions to
* @return the event type for the given event name
*/
public @CheckForNull EventType getEventTypeForName(String eventName, ErrorHandler errorHandler) {
public @CheckForNull
EventType getEventTypeForName(String eventName, ErrorHandler errorHandler) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move the @CheckForNull annotation to before public like how its used on getExperimentForKey. They are equivalent and wont produce weird formatting where public is on different line. That's easy to misread as a package-local visibility.

getEventNameMapping()
.get(eventName);
getEventNameMapping()
.get(eventName);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be single line

@@ -299,7 +296,8 @@ public Experiment getExperimentForKey(@Nonnull String experimentKey,
}


public @Nullable Experiment getExperimentForVariationId(String variationId) {
public @Nullable
Experiment getExperimentForVariationId(String variationId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types. This is formatting is worse.

public @Nullable Variation getForcedVariation(@Nonnull String experimentKey,
@Nonnull String userId) {
public @Nullable
Variation getForcedVariation(@Nonnull String experimentKey,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types. This is formatting is worse.

@@ -67,7 +67,8 @@ public Object getValue() {
return value;
}

public @Nullable Boolean evaluate(ProjectConfig config, Map<String, ?> attributes) {
public @Nullable
Boolean evaluate(ProjectConfig config, Map<String, ?> attributes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types. This is formatting is worse.

@@ -44,15 +44,15 @@ public OrCondition(@Nonnull List<Condition> conditions) {
// false or null is null
// false or false is false
// null or null is null
public @Nullable Boolean evaluate(ProjectConfig config, Map<String, ?> attributes) {
public @Nullable
Boolean evaluate(ProjectConfig config, Map<String, ?> attributes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types. This is formatting is worse.

protected SubstringMatch(String value) {
this.value = value;
}

/**
* This matches the same substring matching logic in the Web client.
*
* @param attributeValue
* @return true/false if the user attribute string value contains the condition string value
*/
public @Nullable
Boolean eval(Object attributeValue) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets update this annotation placement for style consistency


@Override
public @CheckForNull
Void handleResponse(HttpResponse response) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types.

public @Nullable Variation bucket(@Nonnull Experiment experiment,
@Nonnull String bucketingId) {
public @Nullable
Variation bucket(@Nonnull Experiment experiment,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comments about annotation placement for return types. This is formatting is worse.

@mnoman09
Copy link
Contributor Author

mnoman09 commented Jan 2, 2019

@loganlinn I have updated the PR and did all the changes you have asked for.

@mikeproeng37 mikeproeng37 merged commit db15b83 into master Jan 7, 2019
@mikeproeng37 mikeproeng37 deleted the mnoman/codeNitFixes branch January 15, 2019 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants