I definitely prefer more verbose names to abbreviated ones, but I'm not sure that never abbreviating a variable name is the right way to go either. Surely there's a middle ground between `Ttpfe` and `timeOfTenPercentHeightOnTheFallingEdge`?
I like using static types to avoid these sorts of problems. Modern languages like Swift, Rust and Haskell let you make zero-overhead type wrappers around other types.
So here they could have defined `newtype RisingEdge(Float)` and `newtype FallingEdge(Float)`, and then use those types in the function parameters as appropriate.
Helps shorten function names to boot!
I know, [Turbo] Pascal (etc) never had generics. But if they had, you would have been able to make a type with a generic expression, rather than a constantly repeated inline monstrosity of an expression.
Edit: e.g. if all of your variables are "timeOfTenPercentHeight...", cut that part out of the name. Full names can be just as bad as abbreviations - e.g. if they're all "timeOfTenPercentHeight..." then they all start to blend together.
Yes exactly. If you factor out a class that deals exclusively with timeOfTenPercentHeight, then the variable names can be OnTheFallingEdge and OnTheOtherEdge or whatever...
times.tenth.fall
times.tenth.rise
My first paid work in the 80s was in a language with 8 or 10 character long names, depending on use, with only scalar values outside of ISAM tables. One compiler variant extended that with arrays (but not nested arrays). You had no choice but to make some weird names.
That said, when I started doing ANSI C with 32 char names, I felt like I had failed when I needed a variable that had to be that long to explain what it did. Either it had too broad a scope, or should have been bundled in something else (record/struct).