5 ms·
Maybe "good" is relative? Good for whom? For the active developers that work with the same identifiers frequently for a long time, the short names are convenien
by pjtr 10y ago
Maybe "good" is relative? Good for whom? For the active developers that work with the same identifiers frequently for a long time, the short names are convenient and sufficient. All abbreviations are obvious to them, and all contextual implications are clear.
For new developers or developers that frequently switch between working with many different environments the short names can be a huge problem.
"strlen" is not the biggest problem; you can look up what that means, as it's well documented. The problem is much worse when short names and abbreviations are introduced ad hoc without sufficient contextual clues.
Actually bothering to document abbreviations helps. Does "proc" mean procedure, process, processor, ...?
double chnopsnrg;
double chnopsEnergy;
double carbonHydrogenNitrogenOxygenPhosphorusSulfurEnergyInKiloJoulePerGram;
double chnopsnrg; // C.H.N.O.P.S. (Carbon, Hydrogen, Nitrogen, Oxygen, Phosphorus, Sulfur) Energy in kJ/g
I'll take the 4. over the others, but anything over the 1.
Also scope matters. In local scope, names can (and should) be shorter. The context is clear.
let fooBar = ... where fooBarPath = .., foorBarFile = File(fooBarPath)
let fooBar = ... where path = ..., f = File(path)
Public global names are a different matter.
Also tooling matters. In old shells and editors without auto-completion long names of course quickly get annoying. With auto-completion and highlighting of identical words this is less problematic. On the other hand a good "go-to-definition" or "peek-documentation" feature makes short (documented) names less problematic.
I give credit to PowerShell to at least attempt to balance the two aspects, as it supports both long and short names for most things. The tooling aspect seems to have been ignored though.
- userbinator 10y agoWith auto-completion and highlighting of identical words this is less problematic. Autocomplete only helps when writing, not reading; and it doesn't solve the problem of long names which have the same or similar prefices, obscuring the important differences. Long names still require reading. Here's a commmon pattern in Java and C# code: FooBarBazIntervalFactory fooBarBazIntervalFactory = new FooBarBazIntervalFactory(...); ... fooBarBazIntervalFactoryType = fooBarBazIntervalFactory.GetFooBarBazIntervalFactoryType(); fooBarBazIntervalFactorySize = fooBarBazIntervalFactory.GetFooBarBazIntervalFactoryType(); I prefer something more like FooBarBazIntervalFactory fbbif = new FooBarBazIntervalFactory(...); ... fbbifType = fbbif.type(); fbbifSize = fbbif.size();
- deleted 10y ago[deleted]
- pjtr 10y agoAs I said, highlighting of identical words helps a lot with that. Example: https://code.visualstudio.com/images/language-support_document-highlights.gif https://code.visualstudio.com/images/language-support_docume... Also, I always wondered if something like this would work well: https://github.com/ankurdave/color-identifiers-mode https://github.com/ankurdave/color-identifiers-mode
- jstimpfle 10y agoIMHO something is broken with these guidelines and the IDE's we have. Isn't this a contradiction? On the one hand it is argued that long variable names are needed to improve readability. On the other hand tools are needed to read the resulting mess. I've had to develop team codebases in both Eclipse and Visual Studio, and the experience was not good. Not only were the IDEs slow and buggy, but also the code (which followed the long names cult) was terrible to work with. No cohesion, no separation of concerns. Personally, most of the time I'm happy to use vim without any plugins. Most time is not spent typing, but thinking about factorization of the program. Depending on scope I mostly use short variables. I don't expect to be able to dive into code without understanding the context -- the idea that this is possible is a misconception. But it could very well be that the people arguing for long names do e.g. business code (where concepts might or might not be less clearly scoped and cohesive) and people arguing for short names do e.g. more algorithmic code. Without proper scope (ha!) this discussion is worthless.
- junke 10y agoThere is a copy-paste error ;-)