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.
19 Tuesday Oct 2021
Tags
code clarity, computer code, computer programmers, readable code, space character, tab character, text file
There are many issues that divide programmers: operating systems and editors being two huge ones. I’ve worked on too many platforms to care much about the first one, but I’m a lifelong gvim user.
One of the lesser dividing issues involves the crucial source coding choice: Tabs or Spaces? The issue is both less and more important these days. Less because editors are very capable; more because Python is popular.
19 Sunday Apr 2020
Tags
code clarity, computer programming, operator precedence, order of operations, parentheses, readable code, software design
Enough stories, time for a new rule. Which is to always use parentheses in all except the simplest of math expressions. Languages have a precedence protocol, so the compiler can figure it out, but human readers may be confused.
As always, the underlying motivation involves code clarity for other humans reading the source code — the most important rule of all.
10 Tuesday Jun 2014
Think of writing code as you think of writing a formal letter.
When you write a formal letter, you have two goals: you have a message to communicate, and you must follow the protocol of a formal letter. Your message comes through when your writing is clear and good. Following the protocol is a matter of knowing and following some syntax rules.
A message + formal syntax. The result is a document with a context.
05 Wednesday Mar 2014
Here’s a simple tip! I can’t begin to count how many potential code bugs this has eliminated. It takes some getting used to but once you make it automatic it’s a real help in keeping code and your thinking correct.
The tip is this: when you write relational expressions, always use less-than, never use greater-than. (Less-than-or-equal is okay, too.)
03 Monday Mar 2014
When you write code, always remember Rule #2: Source code is for humans. This rule ties to Rule #1 about clarity. You’re writing for humans, so write clearly! The compiler can understand any syntactically correct ball of mud you make, but humans need all the help you can give them. Write for your human readers, not the compiler.
26 Wednesday Feb 2014
Posted in CS101
Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.
The Hard-Core Coder 