4 ms·

Short names actually help with readability when they are commonly used. It's a lot quicker to go over the code when you don't need to read as much, similar to h

by buzer 3y ago

Short names actually help with readability when they are commonly used. It's a lot quicker to go over the code when you don't need to read as much, similar to how one would write something like x+y=z in math instead of putting descriptive name for each variable in each step or using things "1€/kg" instead of "one euro per kilogram" (or let alone including kilogram's definition from SI standard).

lcnPylGDnU4H9OF 3y ago
Despite this, mathematical proofs still use a bunch of plain words to define things. In a programming context, if one has an “user” from the database, “user” is usually a better name than “u”.
- IggleSniggle 3y ago
  It really is a context and frequency thing. For example: users.map(u => u.lastName) Nobody is going to have any questions about what 'u' is here. Do that in a codebase that has a 100% consistent and very frequently used User type, and it starts to feel quite reasonable to just use 'u'. It's as familiar as Apple π.
  - lcnPylGDnU4H9OF 3y ago
    This is a perfect example of why I think it’s “usually” better. Still, the word “user” is there in this case. It could be a lot worse: us.map(u => u.lastName); Maybe that’s too close to the word “us”, meaning you and I. We can do better: u_s.map(u => u.lastName); But then is that an abbreviation of something with the initials “U” and “S”? We can do better: users.map(u => u.lastName); Point being that including the word on the line is what provides the clarity. ---- And a bonus option for the truly maniacal: you_guys.map(your => your.lastName);
    - syntheweave 3y ago
      I believe a programming language could actually codify rules around how long names are allowed to be based on scope. In a local scope, aliasing to single-letters is OK, and many codebases are littered with i,j,k,b,v,x,y,z arguments and iterators. But putting that into a nested scope has produced many errors for me as I accidentally declare a new n or v and then try to access the outer one. So I'd enforce uniqueness when nesting. After some experience with Pascal, I thought the idea of implicitly reserving "result" as the name for the returned value was a good idea, but also a bit long. Taking a page from TI-BASIC I have settled on "ans" for "answer". Global variables generally have to be a bit longer to not collide. In my own investigations, this happens at four characters: while you can devise some two and three-character abbreviations that work at language level, at four you start getting more complete English words(and English is a bit part of this whole estimation, more densely encoded languages will have their own metrics). Types, functions and classes often cause woes, because they need to be accessed across modules, and modules will use names in linguistically dense ways, but they should not expose that as the default interface in most cases. Here I think the goal should be to have full namespace qualification as the default, and then gradual relaxation near the callsite through explicit aliasing and redeclaration. That last part makes me think that I can go further with what I alias in some languages. Eg. in Haxe, I have the freedom to throw in "typedef Foo = com.corporation.big.fancy.Package.Classname.Method" wherever I like.

by buzer 3y ago

lcnPylGDnU4H9OF 3y ago

Despite this, mathematical proofs still use a bunch of plain words to define things. In a programming context, if one has an “user” from the database, “user” is usually a better name than “u”.

IggleSniggle 3y ago
It really is a context and frequency thing. For example: users.map(u => u.lastName) Nobody is going to have any questions about what 'u' is here. Do that in a codebase that has a 100% consistent and very frequently used User type, and it starts to feel quite reasonable to just use 'u'. It's as familiar as Apple π.
- lcnPylGDnU4H9OF 3y ago
  This is a perfect example of why I think it’s “usually” better. Still, the word “user” is there in this case. It could be a lot worse: us.map(u => u.lastName); Maybe that’s too close to the word “us”, meaning you and I. We can do better: u_s.map(u => u.lastName); But then is that an abbreviation of something with the initials “U” and “S”? We can do better: users.map(u => u.lastName); Point being that including the word on the line is what provides the clarity. ---- And a bonus option for the truly maniacal: you_guys.map(your => your.lastName);
  - syntheweave 3y ago
    I believe a programming language could actually codify rules around how long names are allowed to be based on scope. In a local scope, aliasing to single-letters is OK, and many codebases are littered with i,j,k,b,v,x,y,z arguments and iterators. But putting that into a nested scope has produced many errors for me as I accidentally declare a new n or v and then try to access the outer one. So I'd enforce uniqueness when nesting. After some experience with Pascal, I thought the idea of implicitly reserving "result" as the name for the returned value was a good idea, but also a bit long. Taking a page from TI-BASIC I have settled on "ans" for "answer". Global variables generally have to be a bit longer to not collide. In my own investigations, this happens at four characters: while you can devise some two and three-character abbreviations that work at language level, at four you start getting more complete English words(and English is a bit part of this whole estimation, more densely encoded languages will have their own metrics). Types, functions and classes often cause woes, because they need to be accessed across modules, and modules will use names in linguistically dense ways, but they should not expose that as the default interface in most cases. Here I think the goal should be to have full namespace qualification as the default, and then gradual relaxation near the callsite through explicit aliasing and redeclaration. That last part makes me think that I can go further with what I alias in some languages. Eg. in Haxe, I have the freedom to throw in "typedef Foo = com.corporation.big.fancy.Package.Classname.Method" wherever I like.