ThorstenOnSoftWare

From ThorstensHome
Jump to: navigation, search

Parent: What I always wanted to say

ThorstenOnSoftWare is the name of this site. It comes from the blog http://www.joelonsoftware.com that I enjoy every time and that has made my life more joyful. Joel, if you read this, this is not about stealing from you, but a tribute to your great site.

Contents

What makes a good employee

See what makes a good employee.

How to make a bad title

At work, I stumbled across a problem that I want to declare as universal. I got a mail with a title like

christmas party invitation

I deleted this mail without reading because I knew I would not go there. Fine so far. But later I found out this mail contained one sentence that actually was of interest to me:

"due to the preparations of the christmas party, the canteen will be closed starting 12:30"

So, what happened? Someone had created a bad mail title (also known as subject) and as a consequence I could not eat for lunch. This is what I call bad information logistics. Logistics deal with goods being

  • at the right time
  • in the right quality
  • at the right place

Information logistics deals with the same, just "goods" being "pieces of information" (also known as "knowledge"). Structure information wisely. Make good titles and mail subjects. Tell the reader of the subject if he or she should read the mail. Most commercial websites are a mess of "information" but nobody knows what to read. Imagine a company website having only the following items:

  • click here if you want to buy online
  • click here if you want to apply for a job
  • click here for hot-air-powerpoint slides around our products
  • click here if you want to complain

Hey, a site-map would not be needed any more. Just put yourself into the situation of a user/reader.

Now the same stuff happens when you read about regex's. Take the tutorials. It is unbelievable how quickly people get to talk about branches, pieces and atoms and completely fail to understand why you use regex's at all:

Find a line that (does/does not) (contain/start with/end with) (the string/one of the letters/a character range) XXX, followed or not by [same again]

This is exactly what I aim at with my software krep.

Analyzing source code

No idea how often you do it, but I frequently analyze source code that has been written by other people. I think I have some ideas what to not do in order to keep your code understandable. This is good for your colleagues if you program professionally and if you create open source software. It is also good for you if you want to understand what you wrote even in some months.

Tolerance

When analyzing code, tolerance is appropriate. I have only once seen code from another person that I was comfortable with reading. I have never met a person looking at another's source code and being happy with the code's readability. Joel has a nice article saying that it is easier to write code than to read it. The mediocre programmer rewrites code, the excellent programmer understands and improves it.

Method

Let's assume I am running a program and get an error message "fatal error". Let's assume I have the program's source code and the matter is important enough for me to debug it. I will search the string (command ss in PowerShell) in the source code files.

What can go wrong

Well, if you have ever done this on your own, you may know: you find the string "fatal error" only in the translation files and get no clue what to search in the code files. BING! First thing to avoid!

Let's assume you are using the kool KDE framework and find something like

myClass foo()
{
  if (bar()) KMessageBox::information(0,i18n("fatal error"));
}

C++ vs C

When I search for the implementation of bar() in C, it is relatively simple (provided I have Linux, and the function type and name are in one line:

grep -Eir "void *bar|int *bar|bool *bar"

and so on for all first-class citizens.

C++ makes this more complicated because even a declaration like

thorsten bar()

would be legal. It is no longer possible to predict a set of possible function types without going through all includes. In other words:

C++ makes readability--.

subclasses

The same is valid for inheritance. I can remember so much time that I passed hunting someFunction() through a hierarchy of classes. Event inherits from Incidence which inherits from IncidenceBase. Now where is dtEnd() defined? Know that problem?

implicit gotos

The big problem about the goto command is that it makes it hard to predict the program's behavior. From the middle of nowhere, your instruction pointer suddenly jumps "somewhere". I even remember a real programming language allowing the statement

on error goto

But you do not need goto to get this mess. The same is valid for

  • exceptions
  • the signal/slot mechanism

Avoiding these constructs will not only prevent bad weather and make your cat happy, it will also allow you to read the code you wrote some months ago.

Suggested Readings