Hints and Allegations

The Repo on GitHub

I want to discuss something that GeePaw and I were talking about: sloppy code. My sloppy code.

GeePaw sez ta me, he sez:

Look. I have known you to be a sloppy coder.

He went on to say that he is more careful¹, not letting loose ends lay around, or dead code, or tests that aren’t at the right place and the right level.

He might have said, though in this instance he did not, that he generally has a much more solid view of the upcoming design than I have. He might have gone on to discuss how much more pretty he is than I, although I do think he would agree that, as I am a Winter, black is definitely my color. Again, in this instance, he did not.

I think it’s a fair cop that I can produce sloppy code, and in fact I would go so far as to say that I often do. I might rationalize doing that, since the whole theme of my programming here in public is that we can evolve our way from nothing to something, and that we can refactor that probably sloppy something into something less sloppy. I try to show that when the objects are close enough to right, they can be rearranged and restructured to deal with [almost?] any requirement that may arise.

Furthermore, one of the most common article types here is the kind where I pick up on some sloppy code and improve it, to the amazement and illumination of all.

That’s not to say that I am sloppy on purpose: I am not. I have, however, come up with what I think is a useful way of capitalizing on the many opportunities that my code provides for demonstrating refactoring to improve existing code.

Let’s come back to the view one has of one’s desired design. I think GeePaw and I agree that he generally has a more firm vision of the design he’s working toward than I have of mine. I think that if you were to stop me at any given point and ask me how what we’re doing fits in with our overall plan and needs, I would have a fairly good vision of what we’re at and where we’re going … but that vision would be more in terms of clouds than firm rectangles. These things over here in this cloud, those things over there in that one kind of thing. My clouds would be connected sometimes by fuzzy lines if I had a pencil that drew fuzzy lines.

GeePaw’s description, in response to the same questioning, would generally be much more firm. It wouldn’t be drawn in ink, I imagine, because he is open to discovering better ways. But it would be written in darker pencil than my picture. Or so it seems to me. If GeePaw isn’t like that, we can imagine someone else who is. (But he is.)

Both GeePaw and I do the thing he calls “pathing”, which is to try to find small step from green to green, that lead us in the direction of the design we see. I want to suggest here that there are “natural forces” that act on us that are consistent with my “R” code being sometimes more sloppy than his “G” code:

1. When we see a bit of design very clearly, our steps toward it will tend to be more direct, more targeted. So the G steps will likely be closer to ideal than the R steps.

2. G works primarily in strict languages that are less tolerant at compile time: Java, Kotlin, and the like. I work primarily in less restrictive languages, Python, Ruby, Lua, and the like. The G languages will often not even compile if the code isn’t pretty close to what it needs to be: methods have to be there, calling sequences have to have the right parameters and so on. The R languages will tolerate almost anything that’s in the right syntax. So the R steps aren’t constrained so much. I think of paths from here to there. I think that in the non-strict languages, those paths are wider, more tolerant of deviation from right on the path.

3. There’s something down at our cores that is a bit different. G really wants it to be “right” as well as working. He despises what he calls “RORA” code: Runs Once, Run Away. I am not quite in the RORA category but, if only because of how I work here chez Ron, I know that I’ll be back going over this code if it is in any way troubling or needs changing, so I can tolerate a bit more cruft.

4. I am probably, all reasons aside, just more of a sloppy coder than GeePaw is. I am whoever I am, even though that’s different every day, and my everyday work is about as it is, every day. And, as we see often, I can compensate for that characteristic with reviewing and improving code most every time I look at it. Well, sometimes when I look at it.

So, yes, what you see here can often be described as more sloppy than might be ideal. We all make our own mistakes in our own way. The question is what we do about them when we see what would be better, or see ways of working that might be better.

We’ll close this discussion here and start a new article about the code. See you there!