Balance Programming
-
When to warn
If the software you’re developing has a problem then you want to know about it. We use log messages at runtime, build messages at compile time and we can run extra tools to tell us even more about our code. However there can be so many messages they you don’t end up reading them, at…
-
Algorithms are great, minimax
There are problems that are hard to solve. There are problems that are easy to solve if you don’t care about speed. At university the algorithms course was one of my favourites. Finding the right algorithm can mean being able to solve the problem much faster. Maybe you’ll have to discover it yourself but there…
-
Benchmarking tool
I’ve written before about when and how to optimise code. I think there are often more important aspects to a project than code performance. Servers, desktops, laptops and even new mobile phones are many times more powerful than an old computer. Instead you need to decide whether the performance is good enough. That could be…
-
Clean Code
I’ve heard of some people following the Clean Code methodology and some people reacting against it. It’s not been on my reading list before so I got hold of Clean Code by Robert C. Martin. I think it has some good ideas and a few bad ideas. My biggest problem is that these are often…
-
How often?
Don’t Repeat Yourself (DRY) is, ironically, said quite a lot. I think in general this is uncontroversial. If you have a choice between writing a lot of very similar code: Or something smaller that does the same job: You are probably going to choose the later. Maybe you think this is an overly simple example…
-
AI assistance
We now have access to new powerful tools like ChatGPT that can help us write code. There are a number of potential issues with this: So far I haven’t found this useful for situations at work. Every time I had asked for some source there were fundamental flaws with the code. It did sometimes give…
-
Historic programming style
While researching one of my recent post I came across a reference to The Elements of Programming Style. It’s a study of programming style and it was first published 50 year ago. My dad recognised the book and he remembers when you had to make programs using punched cards! Despite it’s age a lot of…
-
Interconnection complexity
This problem is sometimes referred to as communication complexity and can be a problem for teams. It also has implications for systems architecture and probably elsewhere. Team problem One person by themselves doesn’t have to worry about synchronising their work with anyone. There is no communication overhead. On the other hand, it’s just one person…
-
Good names
Code is full of identifiers. Whether that’s variables, functions or types. If you’re doing something to something else chances are that one or both of those involve identifiers. I not going talk about how you format a name for the moment, whether you use camel case, snake case or something else. This is about the…
-
Building to throw away
A lot of my advice here will encourage a methodical approach. I’ve worked on code that is more than a decade old. In that sort of situation the original author has probably moved on, perhaps most people who were working on the team at the time. Having comments and commit messages that explain what the…