I forgot the codez...

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.

A quickie: When you have a class with a builder, and you want to subclass that class, you also want to subclass the builder. But things get nasty quickly, as your subtypes' builder doesn't work nicely. A good solution from Stackoverflow: http://stackoverflow.com/questions/17164375/subclassing-a-java-builder-class Also, a thingie on sizes. When is a class too big, when is a method too big, when is a package kinda big: https://www.javacodegeeks.com/ 2012/12/rule-of-30-when-is-a- method-class-or-subsystem-too- big.html Although I don't agree on the rule of thirty (I think it's too big. Maybe 30/10/10 is more appropriate), it's a good start, and has some nice references.

Yesterday I had one of those days where all of a sudden I'm shown my code isn't as good as it should be. Oh dear. So, something to learn, because they were right . Two things: Static methods Static methods are 'horrible'. After discussing about the why, finally a good argument came up: They inhibit extension! You cannot override them, and usually it is a sign of functional programming style. That may not be bad per se, but being able to override functions is a good thing. So: BE CAREFUL TO MARK METHODS STATIC. USUALLY, IT CAN BE DONE BETTER. Strategies Strategies are cool. However, I tend to push into that direction. That my not be necessarily bad, but strategies are only for compile-time decisions. Ther is a difference between implementing classes which are injected, and thereby selected at 'compile time', and actual runtime by using, say an abstract factory to determine which strategy to use for the current run. So, note to self: only name an i...

Some articles regarding design philosophies: Domain models: rich or anemic? World is at fire, both have advantages, disadvantages. Personally, I'm more of a data-driven anemic model. Where business logic is governed by the business layer, and persistance by the persistance layer, the question is where the domain model resides. I like it more in the persistance layer. This does allow one to hopelessly mutilate the domain model in not allowed ways, but it also SOLID, since it only has one responsibility. http://techblog.bozho.net/on-domain-driven-design-anemic-domain-models-code-generation-dependency-injection-and-more/ https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/ http://stackoverflow.com/questions/23314330/rich-vs-anemic-domain-model And of course wikipedia: https://en.wikipedia.org/wiki/Anemic_domain_model For me, this is also because I'm not much of an OO-fan. Luckily, I'm not the only one: http://www...

Javascript fatigue (or: why it sucks to learn) Organizing code - by strategy, by component, etc. Configuration building in spring Complete java based config in spring Ungit...?

So far I have a number of things which I don't like. Abstract classes are evil.It indicates base classes, but inheritance should never be used for code reuse. Use interfaces, factories, strategies for such stuff. Moreover, they give code that cannot be tested (easily) final should not be used, except to designate constant statics. Nothing more, as it is superfluous take-space-on-my-screen crap Builders which cannot be extended. Ideally, a builder should be separate from the value object, and the value object should be extensible. Hence, private constructors are a no-go for the value-object. The disadvantage of using builders is that it is hard to extend them properly, as they are usually not templated and thus do not use a proper signature. E.g. class OldBuilder {     int a;     OldBuilder withInt(int a )   {         this.a=a;         return this;     }     Value...