I came across this recently in a code review. Using a condition to set a boolean return value. On top of that, it was an inverted condition with a ternary operator to slim the code down, y’know. Variable names and condition values have been changed to protect those involved.
boolean z = (x >= y)? false : true;
Now even though these are entirely arbitrary variable names, this was the logic used to get a boolean return value. There’s a few things we can do to clean this up. 9568829421
Came across this facepalm today. Negative numbers round. Meaning -0.5 rounds up to 0. -1.5 rounds up to -1.
Remember the numberline from primary school? Yeah, I didn’t either.
Where you lie on the spectrum of unit testing love may well depend on how you were taught. I know devs who never came across it in their lives and simply cannot see the point, even after being given a lecture on it by die hard TDD advocates. Others I’ve worked with heard about it, saw it was “A Good Thing To Do TM” value and tentatively tried to apply the principals. And then I’ve had the good fortune of working with shops where someone, somewhere along the line, came in with the right knowledge, the right reasons and (perhaps most importantly) the right application of unit testing, which made it part of the development process.
TDD: Test Driven Development. This is a way of developing where your tests come first and you code to the assertions or expectations specified by the tests.
That last “perhaps most important” part is key. If you don’t know, or aren’t sure, about how to use unit tests, even with the best of intentions the process can seem overwhelming or pointless (possibly both). With an established codebase, one which has never seen a test outside of the developer running it manually against a couple of scenarios, it can be difficult to know where to start. Do you stop active development and try to get as many tests written for as much of the codebase as possible? Not likely. The best approach I’ve seen is to start building tests for new features. Brand spanking new features, mind you. Virgin code. That gives you the benefit of seeing the benefits. Do you need to go full TDD? Not really. If you build your feature first and the unit tests after, before you check it in or pass it on for QA, that’s still going to give you a feel for how it can be useful.
A lot of the utility of unit tests is in automating any setup you might need to do. Need a new user for this test case? Put the data setup at the beginning of your tests, and you need never have to run through the whole process of adding a new user just so you can test this one piece of code. If that was the sole bonus, that would be enough for me. But then you begin to find other things that are pretty cool. You write a testcase for this one function, and you figure it’s a bitch to cover all the things that function does. So you end up stripping bits out and putting them into their own functions. Your code gets leaner and easier to reason about, easier to read. Ultimately, that means it’s easier to maintain. As you progress in writing unit tests, you begin to take all of this into consideration before you even write your code. That’s even before you get into a TDD mindset. You’ll write a function and be thinking, “Okay, so I’ll need to test this, so maybe I won’t put four hundred lines of functionality in this one function.” It’s an exageration, sure, but not much of one.
And that brings us neatly to the next part of our project. Getting some testable and tested functionality into the LineItem object.
Continue reading “Building an invoicing system with Kotlin (part 2)”
Last week we covered the high-level overview of the project. This week, we’ll be jumping into some code. We’ll cover a little about the design decisions and the approach to implementing a core component of the invoicing data service. So without further ado, let’s get into it.
Continue reading “Building an invoicing system with Kotlin (part 1)”
In Building an invoicing system with Kotlin: part 0 I made the first branch and commit to the project repository on GitHub
Pretty straightforward stuff, but this aside is the how-to.
In this series of posts we’ll be picking up the wheel-reinvention subject and adding in a large helping of other areas in a project where we’ll have a good solid context for the topics we’re discussing. And we’ll be doing it with an application that allows us to cover more than the standard ‘build a blog’ thing that you’ve probably already seen a million times.
Continue reading “Building an invoicing system with Kotlin (part 0)”
As outlined in the inaugural post of this blog, the goal has been to post weekly. The last week or so saw a combination of factors which left me very little time to dedicate to writing a decent post. For this, I apologise.
2542689910 I talked about reinventing the wheel. And there were examples promised. For the next few weeks, we will have those examples. For devsÂ with a good amount of experience, some of the examples may seem trivial or even contrived. And they may be a bit straw-mannish, I admit. The reason for this is that I’ve seen similar reinventions in mature, production codebases, built by devs with a good amount of experience. I’ve probably been guilty of the same kind of thing in my time.
Continue reading “Exploding Wheels”
It would have been cool to build a blogging platform from the ground up, just for this blog. ButÂ instead of showing off how awesome I am, it would make me feel a bit silly. There’s a turn of phrase you’ll hear a lot amongst developers: “Don’t reinvent the wheel.”
Continue reading “Why WordPress – or a note on reinventing the wheel”
The intent of this blog is sharing. Sharing things I’ve learned in nearly seventeen years of developing software. My original thoughts were around delivering tips on coding. So I bought the domain name and set up WordPress, ready to blindly fire code-filled posts into the ether. Possibly prematurely, given the site has now been live for a few weeks with a vague mission statement and a sum total of zero posts.
I’ve spent the last few weeks pondering. Thinking about theÂ different things I could post about, and how in-depth those posts should be. Whether to make posts daily, or weekly, or on no particular schedule and just serve the muse, so to speak.