This post will try and maybe fail to convince you that using null
in your code is an error.
For those of you willing to listen, here are my reasons to stop using it.
4 Jan 2016
One of the things that makes TDD difficult to apply on existing code (or just “legacy code”) is the dependencies that the object subject to test may have. The more “dependencies” the object has, the more difficult it will be to test it, almost for sure.
What makes things even harder is that usually most dependencies are incorrect, there is an unnecessary coupling between objects result of bad designs (yes, there are good designs and bad designs as there are good paintings and bad paintings, good music and bad music… being the definition of good and bad relative to a set of principles or rules. At least there is a design principle in software development that we all agree on that looks to maximize cohesion and minimize coupling. So the more unnecessary dependencies, the bigger the coupling, the worst the design is).
16 Feb 2012
Today we all know now that variables should not be called x
or y
, not even i
nor n
when we use the famous “for”… but do you know why? have you had
trouble naming a variable? and what about a method (message) or a class?
The truth is that naming in software development is really important, so important that I usually say that programming is “the art of naming”.
2 Feb 2012
One of the recurrent problems I see when teaching OO design is the “names” used by the programmers to name classes, methods, etc.
The problems are different depending if attendees are from the industry or the university. At the industry I see that names are wrongly selected, bias technology names, while at the university it is common to see the lack of ideas to name things (which makes sense because they have less experience). I will concentrate on the problem I see at the industry.
12 Jan 2012
Patagonia is a conference registration web based system written in Pharo using Seaside, whose main purpose is to fulfill the ESUG conference registration needs. It was developed at 10Pines under the sponsorship of ESUG. It has been develop using some design principles that were “grown” developing other two systems, being Patagonia the latest version of them. These design principle’s objective is the development of “robust” software, that is, software that can easily change in a safe fashion, being at the same time self defensive when used incorrectly and self “teachable” to new programmers of the system.
2 Oct 2010
object-design code-reuse smalltalk inheritance
When talking about Smalltalk, there is definitively an over use on the possibility to add messages to Object
class. It is so easy to do it, that people usually do it just to get something working fast, even if the coding is poor. There are a lot of messages (mainly #isXXX
messages) that do not belong to Object
and represent a bad design decision. Most of them are implemented there because they are “handy” and easily “reused”. For example #->
or #assert:
implemented in Squeak. Definitively not all objects should respond to them.
20 May 2009