id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
11447	recent coding style changes	bastiK	team	"A lot of work has been done recently to improve the overall code quality by using automatic code scanning tools. The vast majority of those changes I fully support, but there are some minor things I would like to discuss / reconsider.

[8384]:
* It is wrong to use `Utils.equalsEpsilon` in `@Override equals` as it violates the principle that equal objects must have the same hash code (e.g. in `LineElemStyle`)
* It is not always an error to use ""=="" for floating point comparison, sometimes it is intended. For example in `StyleCache`, with equalsEpsilon it becomes a gamble that the code works correctly. I could construct a corner case example where it would throw an AssertionError. (similar problem in `GeoPropertyIndex`, I think)
* Why do you change `x == 0.0` to `Double.doubleToRawLongBits(x) == 0`? First of all, it looks silly. [[br]]The performance improvement (if any) should be negligible. Next, it also changes the semantics. E.g. in `ExpressionFactory.Functions.divided_by(x, ..., y)`, before dividing `x / y`, it checks if `y` is 0.0 or -0.0. Now it only checks 0.0. (same problem in `Geometry`)

I can fix these things myself, just like to give a chance to comment. :)"	defect	closed	normal	15.05	Core		fixed