I had approximately a month between when I wrote it and reread it. While it was serviceable in short-term memory, comprehension suffered noticeably in the long term with four-letter or less names.
At the time I did this I was pursuing Arthur Whitney's extremely terse style to see what advantages and disadvantages it brings. My main modification was to add a full description comment inlined into the declaration of every variable, a practice which I have mostly kept up with even after the experiment ended, e.g.:
var tz : String; /* time zone */
This meant that I was not testing on whether I could reconstruct the entire meaning in my head, just whether it made code flow better to use very short names. My discovery was that it does help, up to a point, because you can always create original short names that differentiate better than long abbreviations:
result = ttpfe + ttpre;
vs.
result = q + k;
Any time you copy-paste-modify, you create a risk of error. Including the whole phrase slows down your reading and brings diminishing returns on comprehension as it puts friction on actually working with the variable. With the highly differentiated "q" and "k", error has a lower likelihood of slipping in than the abbreviation because you've minimized the amount of noise in the data - it "chunks" better and you can read the whole algorithm more fluidly. The only problem with using such short names is the issue of reconstruction, which is why I opt for aliasing a long name if I need to work with it frequently, even if it means extra boilerplate to make a local variable. Abbreviation is the worst of both worlds and so I try not to do so much of it.
Given the original 8-character constraint of OP I might have tried something along the lines of:
"edge_t0" "fall0" "ef"
Because there is no way to convey the entire phrase, I see it as preferable to focus on a key aspect, expand that word, and push everything else into more symbolic content, especially numbers. Programmers are already trained to look carefully for uses of 0 vs. 1 in our code. That doesn't mean it's my go-to for an abstract symbol, but it works better than a bad abbreviation.
At the time I did this I was pursuing Arthur Whitney's extremely terse style to see what advantages and disadvantages it brings. My main modification was to add a full description comment inlined into the declaration of every variable, a practice which I have mostly kept up with even after the experiment ended, e.g.:
This meant that I was not testing on whether I could reconstruct the entire meaning in my head, just whether it made code flow better to use very short names. My discovery was that it does help, up to a point, because you can always create original short names that differentiate better than long abbreviations: vs. Any time you copy-paste-modify, you create a risk of error. Including the whole phrase slows down your reading and brings diminishing returns on comprehension as it puts friction on actually working with the variable. With the highly differentiated "q" and "k", error has a lower likelihood of slipping in than the abbreviation because you've minimized the amount of noise in the data - it "chunks" better and you can read the whole algorithm more fluidly. The only problem with using such short names is the issue of reconstruction, which is why I opt for aliasing a long name if I need to work with it frequently, even if it means extra boilerplate to make a local variable. Abbreviation is the worst of both worlds and so I try not to do so much of it.Given the original 8-character constraint of OP I might have tried something along the lines of:
"edge_t0" "fall0" "ef"
Because there is no way to convey the entire phrase, I see it as preferable to focus on a key aspect, expand that word, and push everything else into more symbolic content, especially numbers. Programmers are already trained to look carefully for uses of 0 vs. 1 in our code. That doesn't mean it's my go-to for an abstract symbol, but it works better than a bad abbreviation.