30 Monday Jun 2025
In the previous post I semi-corrected a long-time oversight by revisiting the post The Thing About Constants and turning it into a Coding Rule, Rule #6. (I say “semi-corrected” because it really should have been Rule #3.)
In this post I semi-correct another oversight represented by the post The Synchronization Problem. It’s the other one that has been bugging me for a while because it should have been a rule (probably Rule #4). As they say, “Better late than never.”
23 Monday Jun 2025
Posted in CS101
Tags
code clarity, computer programming, constants, defined values, global constants, literal values, readable code
It has been more than a few minutes since I posted a Coding Rule, so I thought it was high time I did. There are at least two things I’ve previously written about as important but didn’t elevate to Rules. Both have been bugging me; they should be rules. Today (and a week from now) I’m correcting that oversight.
To be honest, this Rule is so important, I’m not sure why I didn’t make it the third one. Rule #1 and Rule #2 are definitely more important, but the ones currently listed as #3 – #5 are not as important as today’s (they are very important, though).
16 Monday Sep 2024
I’ve never been particularly interested in puzzle games. Figuring out software has filled that niche for me (plenty puzzling enough). So, I’ve never done a Sudoku puzzle. Recently I read a post about Tredoku, which is a kind of three-dimensional Sudoku.
In that post was an unsolved Tredoku puzzle. I wasn’t tempted to try to solve it myself, but I did think it might be fun to see if I could write some Python to do it.
19 Monday Aug 2024
I recently learned about Bloom filters (and was then able to fully understand the joke in this xkcd comic). While I don’t have a good application for them myself, I found them interesting enough to play around with a little.
Python uses them under the hood in a way that has some potential for other applications. In this post I’ll explain Bloom filter basics and go over some simple implementations.
27 Monday Dec 2021
The first article (long, long ago) about naming things only scratched the surface. Even with company and language guidelines (or other rules) to help, with so many things to name it’s easy to lose control. Even now, after 44 years of writing code, I still sometimes find myself staring at the screen trying to think of what to name some object.
It’s understandable; there are a lot of things to think about when it comes to a name.
29 Monday Nov 2021
Posted in CS101
One of the great battles programmers fight involves synchronization between two different parts of the code. The most common example of this is what the comments say versus what the code really does. Another common example is the structure of data stored somewhere (like a database) and the code that manipulates it.
A lot of the programmer’s effort and technique is devoted to managing, if not preventing, synchronization issues. The rules encouraging encapsulation, or against global objects, have a lot to do with this goal.
19 Friday Nov 2021
Posted in Stories
When I was a callow young programmer learning the ropes and enjoying the sheer power of the C language, I got a bit carried away with the macro pre-processor’s ability to let you redefine the language.
As much fun as that is, and as much as it can make your source code look cool, it’s a really bad idea. At some point the folks in comp.lang.c read me the riot act about it, and they were right.
02 Tuesday Nov 2021
Posted in CS101
Tags
code clarity, computer code, computer languages, computer programming, Java, Python code, readable code, toString, __str__
Although I’m categorizing this one as really good advice, rather than as a rule, I think it should be viewed as basically a rule. I think it should be a rule in any object-oriented language that supports it natively (Java and Python, for example).
The advice (rule of thumb, say) is to always create a useful implementation of toString when you create a class. It makes your development and maintenance life ever so much better.
05 Friday Feb 2021
Posted in CS101
I’ve been going through my old Computer Language magazines, and man have things changed since 1984. It’s a fascinating trip through the early days of personal computing.
I was reading an article about using dates in an application and was struck by the prescience of one bit.
22 Wednesday Apr 2020
Posted in CS101
Tags
computer code, computer programming, function currying, Python code, software design, software development
I saw a video recently about function currying, and it triggered the realization that currying might solve a problem I’ve been pondering in the context of language parsing. The problem involves knowing how many arguments an operator expects, what’s called the arity of an operation or function. It can vary from zero to many.
It occurred to me that, with currying, there could be a language where operations always take just one argument. That would solve a challenge for a mathematical expression language I have in mind.
The Hard-Core Coder 