Hi Vladimir, Do you have any idea how this rules may be automatically controlled by, for example, code inspections and/or TeamCity?
I do beleive if rule is controlled by some automatic way (not only by argreement) it has a chance to become true practice in real life. If this excellent idea remains only agreement on dev list, it may be forgotten in the future. Sincerely, Dmitriy Pavlov вт, 16 мая 2017 г. в 13:01, Vladimir Ozerov <voze...@gridgain.com>: > Igniters, > > Ignite is known to be complex product. Partially this complexity comes from > ... complex problems we are trying to resolve. But partially it comes from > how we write our code. I noticed several anti-patterns which makes our code > hard to manage: > > 1) Inner classes (both static and non-static) > 2) Usage of generic tuples > 3) Usage of many classes from our "lang"package - closures, predicates, > etc.. > > When combined these anti-patterns makes our classes huge, leaky in terms of > abstractions, hard to follow and refactor. I would like to propose to > restrict usages of these constructs as much as possible in non-test code. > Classes should be top-level by default, unless "inner" semantics are > absolutely necessary or saves a lot of code. Tuples and closures should be > replaced with concrete classes, specific to your case. > > Thoughts? > > Vladimir. >
