When refactoring an old project

I've just completed a small demo-ish game (GitHub). I decided not to make a full game, and therefore wanted to emphasize this intent by using 1-bit graphics.

My project aim was merely to develop a game in TypeScript very much like a game I did two years ago in JavaScript, and compare. It was an interesting experience.

What do we speak about when we speak about refactoring code?

We need one, or more, measures to evaluate the difference, the new code. First, we ask what is our intention? But we also ask if the changes have a price? Perhaps we want better performance and therefore are forced (depending on the problem at hand) to lessen the readability by using an advanced algorithm, or perhaps we can better both performance and readability.

From linguistics, it is known that the use of shorter sentences with shorter, more common words will typically make a text easier to understand. However, we also know that the phrasing 'typically' almost obliterate what was just said. Sometimes wordy reasonings make a complex argument easier to comprehend. Sometimes this is not the case. True also in the context of programming; there is no general formula.

When we speak about technical jargon as something that may alienate a reader, we must keep in mind that technical jargon usually - that's the point with jargon - makes a text easier to comprehend, if you have previous knowledge of the subject matter. So, if we want readability, we must ask who our reader is? Can we speak about an overall readable code? Yes, in certain regards, but only to a certain extend.

Some speak of readable code as if it something 'given', but just as readable prose must have a clear norm for such a distinction, so do code.

I enjoyed 'redoing' this game, very close in functionality to my old, but in most respects simpler. Something I should have done from the start though is to establish what to focus, what norms to use. Perhaps the next time around?