Justified Variables: Words of the same length with related meanings

To be fair, you could argue that your mentioned behaviour is an undesirable feature of current revision control software and code editors. The formatting could be declarative, so that compiler-meaningless indentation is not on disk. And, compiler-meaningless changes could be ignored by revision control (that's probably provided if meaningless changes aren't persisted to disk in the first place).

It maybe depends on who's going to be interacting with the code in what ways.

If you expect the code to be changed infrequently but read frequently, and if you think the justified version is easier to read or harder to miss errors in, then that could easily outweigh the cost of noisier diffs.

(I'm not sure whether I actually believe the following argument, but:) The increased likelihood of merge conflict is not necessarily a bad thing. If you've got a bunch of variables, structure entries, or whatever, that are related to one another, then if A changes one of them and B separately changes another this very well may be the sort of thing you need to look at carefully and explicitly, which is what getting a merge conflict forces you to do. And (maaaaybe) the more closely related nearby variables (etc.) are, the more likely people who like justified code are to justify them.

Full disclosure: I sometimes justify things in code, in cases where I think it helps to clarify relationships between nearby lines. I don't remember ever getting a merge conflict as a result, or having colleagues complain about noisier diffs. But I've generally worked in small teams and I've often been the only person working on a given bit of code, and what works well in that context is not necessarily the same as what works if you have a much larger group all poking at the same code.

As for golang, I think the pros outweigh the cons here. Code is read more than it's written. Cleaner code means you can literally identify code structure from afar. Which in turn makes is easier to focus on the part you care about. If you have to pick a length for automatic formatting，the same length makes sense. So is trailing commas.

Even if only half of engineers think this is true, the other half should be pragmatic and let the go formatter do it's thing. The best thing about go is that it has one standard formatting.

As for equal length variable names, the majority of these examples you would use naturally anyway, so I am not sure what are you so upset about (top/not instead of true/false is a bit overkill)

I used to hate it until I worked on a team that preferred it. Now I find more than a handful of lines without alignment hard to read. I’m not saying everyone would change their mind, but I suspect a lot of style preferences are more rooted in familiarity than we necessarily realize.

> I think using variables of equal lengths with opposite meanings is an anti-pattern.

Perhaps the worst example of this is Kotlin’s var/val. I much prefer var/const.

I use a CLI app that is used like this:

`command get/set [long directory]`

Because of that long directory part, I use the command history instead of retyping the whole thing. I probably already lost a cumulative total of hours executing `set` instead of `get` by mistake.

Equal-length variable names help to see differences in the remainder of the line. You are more likely to spot mistakes in code where stuff that should be the same is aligned the same.

Maybe, but there’s no amount of elastic tabs that are going to make the suffix in

    nextAncestor
    previousAncestor

line up the same way as

    nextAncestor
    prevAncestor

so I admire the author’s time spent collecting these word groupings.

One nice thing about Julia is being able to use Unicode characters in variable/constant names, e.g. π and θ, instead of the usual pi and theta, in programs.

In geometry, it's conventional to use Greek letters for angles. If you have two angles, theta/phi or alpha/beta are reasonable names for them. Probably better than angle1/angle2 (in which the names are mostly "noise"), but if the angles play specific roles then it may be better to use informative names: azimuth/altitude or whatever.

In finance, there are lots of traditional Greek-letter names. Using gamma/delta/theta is probably _more_ immediately comprehensible to your audience than, say, secondOrderUnderlyingSensitivity/underlyingSensitivity/timeDerivative. (Of course, in this case you don't get to choose which Greek letters you use.)

There are other contexts where particular Greek-letter names are traditional. Again, usually you don't get to choose which ones you use (at least, not if you want to get any familiarity advantage from using them).

When doing algebraic manipulations, sometimes it's convenient to give one set of variables Latin-letter names and another "parallel" set corresponding Greek-letter names. E.g., if you're doing plane geometry, maybe one point is (x,y) and another is (xi,eta). In software, this is probably a strictly worse strategy than calling them (x1,y1) and (x2,y2) or something of the sort.

Two examples of times I have used Greek letter variable names: (a) Often times the Greek letter is the standard way of referring to a concept, e.g. "beta" in a linear regression. For these situations, the Greek letter would be used in spoken language to refer to the concept and is more clear than trying to describe the underlying concept in English. (b) If you implement a non-trivial mathematical equation, it is clearer to use the variable names which are found in the published equation than to try to rename them. To understand the equation, people will need to read the published description anyway, and it is easier to map one to the other if you don't change the names. Likewise, if you are implementing your own equation, you will usually use Greek letters in the paper, and for consistency, you should use the same variable names in the code as you do in your paper.

I only knew of the word Moxie in the context of the Pokemon ability[1] and it never occurred to me until just now that it's a real word with a real meaning haha

> moxie

> n. The ability to face difficulty with spirit and courage.

Thanks!

[1] https://bulbapedia.bulbagarden.net/wiki/Moxie_(Ability)

In maths it’s very common to refer to top and bottom in an ordered structure. I often define a TeX macro \bit as \perp.

Well the next step is to select language primitives based on their character length: > vs >=, + vs ++, == vs ===, var vs const, map vs filter. Or you could select the appropriate function argument count based on total character count. So many opportunities to improve readability.