6 ms·
Naming is related to scope and I'm surprised there is so little about it in the article. While trying to find an universal principle I came up with this rule: "
by gluczywo 10y ago
Naming is related to scope and I'm surprised there is so little about it in the article. While trying to find an universal principle I came up with this rule: "identifier's entropy should be proportional to its scope".
Global variables (if any) are long explicit phrases while inner loop variables can be a single letter.
Without taking scope into account the naming guidelines become dogmatic and impractical trivia.
EDIT: wording
- eecks 10y agoI always name my variables descriptive names. For example, if I am in a loop and the variable represents a "record" I will name it record rather than r. It's much more readable and you're less likely to get name clashes with other functions (r could be lots of things (even in the same file) - render, record, row, red, right)
- tomatsu 10y agoI always go with plural for lists and singular for iteration variables. for (let thing of things) {...}
- TeMPOraL 10y agoPersonally I have a habit of avoiding that, especially in dynamic languages, because a single typo could have nasty consequences there. So I always figure out a synonym, or use a name for the variable that's either more descriptive: for (let particularThing of things) or at least visibly different: for (let th of thigns)
- tomatsu 10y agoThe dynamic languages I primarily use are TypeScript and Dart. I always have enough type information floating around to catch this kind of thing. But even in JavaScript it wouldn't be much of an issue since it will instantly explode on the first run, which is certainly inconvenient, but nothing major.
- euyyn 10y agoIf you name a variable with broad scope "record", though, you deserve hell.
- fsloth 10y agoThis is the best single guide on naming ever.
- gohrt 10y agowhy "entropy" and not "length" ?
- TeMPOraL 10y agoI've been reading Code Complete recently, and this is exactly what the book recommends for variable names :).
- gluczywo 10y agoI had no idea the rule is a classic. It's frustrating that with a little more education I would have spared plenty of time spent reinventing the wheel.
- TeMPOraL 10y agoI don't shy away from reading programming books and I have close to two decades of programming experience now (including hobby times), and this is the first time I've actually read this advice. It doesn't seem to be widely spread. So I guess the choice of books matters...
- jstimpfle 10y agoI identify OO culture as a possible culprit. OO is not so fond of structuring and scoping mechanisms besides classes.
- morbidhawk 10y agoIn addition to scope, I think language syntax plays a role and naming is thought of differently in JS vs C#. In C# you could have a method that takes in 2 points: Point p1 and Point p2 parameters. Since you can see the Type is Point in the parameters it doesn't matter that you abbreviated it so much. In JS though you don't specify types, so point1 and point2 (or pointA/pointB) might be better, unless of course the function name is so obvious (like getMidpoint) in which case p1/p2 or a/b naming would still be clear. I actually really like reading/writing code that uses really small variable names but are still very obvious given it's context (usually never acronyms though, I despise those). I'd always rather working with something small like p1 rather than something very descriptive like sceneOffsetPoint1, especially if I can read the code above it that shows it being assigned based from the scene center point: let p1 = scene.center + Point(2,3);