Archive

Posts Tagged ‘Coding-Style’

Functional Java – partial function application, the LOD and structure agnostic access

March 21, 2016 Leave a comment

It’s been a while since I last wrote something about programming on my private blog and since a lot has been said about Java 8 lambdas, I did not feel to add a lot more. But I recently saw a colleague’s blog on Intel’s Inside Blue about Lambdas and why a functional programming style matters. That motivated me to write something again, and tackle this topic, putting an emphasis on a specific problem and how Lambdas helped me solve it.

Read more…

Advertisements

Into the Void: Refining Java beans with rare weapons

July 17, 2011 2 comments

Lately I’ve been experimenting with the Void class, because I asked myself what I could do with it that I haven’t yet thought about. I came across a use case that I’d like to share with you, because I think it is possible to beautify one’s code with it. In the process of slightly refactoring a Java bean in order to get a nicer, more refactoring-proof way of dealing with beans and reflection, I’m also using an inline-assignment in a way that you might already have come across, still I have hardly seen it anywhere in the wild, even though I find this particular use case for inline-assignments one of the best there is.
Read more…

Don’t handle just another state if you can query, please!

April 14, 2010 2 comments

How often do you find yourself having trouble to understand a big chunk of code? At the moment I’m pretty busy with refactoring just another controller. Even though the number of WTF/min from my office is quite large at the moment, I’m not angry with the fellows who wrote it. The code was made under time pressure and as far as I’m informed, people were under constant threat to be criticized for introducing a bug by changing working code for no apparent reason. Unfortunately refactoring and code cleanups are sometimes hard to sell as “apparent reason”, especially to non-technical staff. As a result code quality starts to decay, changes take longer than necessary and refactoring gets harder every day. I’m placing my bet on my “new kid on the block” credits to go for the risk of breaking code at the moment. So what’s making my life hard at the moment? State! Read more…

Categories: Uncategorized Tags: ,

Minimizing ripple effects

April 6, 2010 1 comment

In the good old times when racing was dangerous and sex was safe and real programmers coded machine language we were used to use jumps and branches to addresses or labels if you had more than just a ML-monitor. BASIC just took this paradigm to a higher language level and the art of programming involved tracing all the jumps and conditions at the same time until Edsger Dijkstra spoiled it all – and rightly so! There are better ways to waste your testosterone and show you’re a real man than working successfully with untraceable spaghetti-code no one else understands – including yourself some months later. Sadly you can still create a tangled mess if you’re programming in Java and other OOP languages alike. Often you find yourself in a situation where you have to change something which would break a lot of code, because that small change you need to make ripples through several classes. The higher the fan-in-complexity of your code is, the worse it gets. This is why some code analysis tools punish a high fan-in-complexity, which may be misleading if you take the DRY-principle seriously. Especially if you work on frameworks you need to take countermeasures to avoid ripple-effects so you can continue to develop your framework while it’s being used. Let me introduce you to a coding style that helps to reduce ripple effects.

Read more…

Using annotations for validation

March 20, 2010 2 comments

There is one common case I often come across and that’s validation of parameters. There are different situations in which you like to validate parameters, the most common case is validation of method parameters, usually performed with guard-clauses and assertions. This is not what I’d like to write about in this blog. I may come across this later. This time it’s all about annotation driven validation on fields. Read more…

Dealing with immutability and long constructors in a fluent way.

March 10, 2010 9 comments

I use to state that the best thing to do is to keep your code simple and clean. But if your task is to design an easy-to-understand and easy-to-change API, this may be a bad advice. There simply is no silver bullet in programming and simplicity ain’t one either.

There is a common case you may have encountered more than once, which is long constructors with repeating types. You’re likely to see them in immutable classes. I’m not going to discuss why immutable classes are desirable, I’m going to talk about easing the pain to construct them. Read more…

Boolean parameters considered harmful – almost

February 24, 2010 4 comments

I have to admit this blog’s title is a bit exaggerated, but since I have lately seen some bad examples of using booleans as parameters, I just felt the urge to write about it.

Read more…