Daniel Keep wrote:
That way, if someone writes logging functions one day that takes formatted strings in the same way, he can reuse the convention:log logLine logFormat logLineFormat instead of "log", "logln", "logf", and "logfln". If you create a hash function, you can reuse the pattern too: hash hashLine hashFormat hashLineFormat instead of "hash", "hashln", "hashf" and "hashfln". And it goes on.How is this an improvement? If we accept that people know what the "f" and "ln" suffixes mean (and given that they will be exposed to this in the course of writing a Hello, World! program), what benefit is gained from increasing the length and complexity of the identifiers? Saying you can re-use the convention is irrelevant because the exact same thing can be said of the shorter suffixes.
The thing about one-letter abbreviations is that they mean different things in different contexts. An "f" might mean "formatted" in a "writefln" function, but it means "file" in an "ifstream" and "floating point" in the "fenv" module.
In those cases (and in many more), there's no convention than can be reused. You just have to memorize stuff. Memorization was a perfectly acceptable solution back in the days of C, when standard libraries were small. But I think any modern standard library, with scores of modules and hundreds (or thousands) of functions, needs a better strategy.
Coming from a Java background, I much prefer to give up terseness in favor of clarity. Though I recognize that verbosity has its own pitfalls, I think it's the lesser evil.
--benji
