[HN Gopher] A Dictionary of Single-Letter Variable Names
___________________________________________________________________
A Dictionary of Single-Letter Variable Names
Author : todsacerdoti
Score : 29 points
Date : 2024-10-12 05:34 UTC (1 days ago)
(HTM) web link (jackkelly.name)
(TXT) w3m dump (jackkelly.name)
| t-3 wrote:
| I like to use 'n' as an index when decrementing the counter.
| Dwedit wrote:
| C# basically forces "e" to be the name of EventArgs in any event
| handler. You can change it, but it will always default to "e".
| ZeroClickOk wrote:
| I have a hard time normalizing existing codebases where coders
| insist on using `catch (Exception e)` instead of the default
| `catch (Exception ex)` and then there are clashes in event
| handlers with try/catch due to the same variable name...
| chaboud wrote:
| I thought this was going to be a bit of dry humor before I
| followed the link. It's actually serious, and fairly informative
| (albeit a bit scary).
|
| The first place I worked had a _soft-but-hard_ rule (enforced by
| ridicule) that single-letter variable names not be used. Loop
| counters like i, j, and k were frowned upon. However, counters
| like ii, jj, and kk were fine for matrix operations, xx and yy
| for image loops, etc.
|
| There were a couple of key guidelines to follow:
|
| 1. If it can have more meaning than sample, pixel, or matrix
| position, give it more meaning, but two characters repeated is
| fine for loop counters (again, with meaning).
|
| 2. Whatever you use should be quickly findable with text search
| tools of the era (the late '90's).
|
| Someone shouldn't have to use source inspection assistive coding
| tools to parse the code you write. When someone else (or you, in
| a few months) comes upon this code and needs to understand it,
| they should be able to use find to do it.
| artemonster wrote:
| As someone who is used to code in python and typescript explain
| to me in layman terms why the HELL would you need something like
| this: "...in lenses or other optics. The simplest complete
| example is a Lens s t a b: it can extract an a from an s and
| overwrite it with a b. Doing so would produce a value of type t."
| kristopolous wrote:
| Haskell is by mathematicians and for mathematicians. I know
| this sounds absurd but many actually find it to be the easiest
| programming language for them. I've met mathematicians who
| claim they were not able to code until they found Haskell.
| cstrahan wrote:
| Sure, I can do that.
|
| Why the HELL would you need objects and object oriented
| programming? Wherever you do foo.blah(), you could just do
| foo_class__do_blah(obj)... so what do objects really grant you
| that you can't do with basic procedural programming?
|
| Why do you need Python's function decorators? You can just
| manually copy and paste whatever logic you need into each and
| every function, instead of decorating them.
|
| Why have an iterator protocol? Every datum can have it's own
| bespoke way of iteration that you simply have to memorize on a
| case by case basis (and can not be abstracted over in any
| common way), why make everything conform to the same interface?
|
| Why have anonymous functions that can close over their lexical
| scope (what people usually refer to as "closures")? Consider:
| let x = 0; let inc = () => x++;
|
| You could just write: function inc(bindings) {
| return bindings.x++; }
|
| And then remember to pass along bindings whenever you need to
| call inc. Besides, that's more or less what's going on behind
| the scenes.
|
| I could keep going.
|
| We have these facilities not because they are essential (go
| program in assembler, and you'll see how few programming
| techniques and concepts your processor actually cares about),
| but because they are nice to have. They are nice to have
| because they provide us tools for abstraction, so by solving
| the general case, you solve a host of concrete cases.
|
| Lenses let you abstract over data traversal and projection.
|
| Maybe you don't appreciate that, and that's fine. There are C
| programmers who don't mind writing 100 different hash tables
| for different keys and elements. If you are a Python/TS
| developer, I'm pretty sure you'd find that surprising -- if you
| want a dictionary/hashtable, you just use a dict and call it
| done -- you _wouldn't_ go build a new dictionary class for each
| and every key-type /value-type pair.
|
| Different people have different tolerances for the drudgery of
| solving the same problem for the 100th time.
|
| However: while I don't understand why someone would choose
| vanilla ice cream if they're given the option of chocolate, I
| wouldn't act flabbergasted in such a scenario. Why would I? Why
| should I expect my desires to be the same as everyone else's?
|
| The only reason I can think of that someone would express shock
| at someone choosing vanilla over chocolate is if they think
| that the preference for vanilla indicates something is
| fundamentally wrong them. Or in other words: being a
| condescending bigot.
|
| That's kinda how you're coming off.
|
| In the event that you were actually asking in good faith: if
| you like to broaden your skills so you can finish programming
| work faster, I'd recommend reading up on lenses. If you don't
| care about that, that's fine too, but I'd recommend against
| expressing shock at the fact that others do care about these
| types of things.
| pona-a wrote:
| [delayed]
| vips7L wrote:
| Part of the reason why Haskell never took off. This stuff is
| incomprehensible.
| semi-extrinsic wrote:
| Fortran's implicit typing sends its regards from an IBM 704.
| dvt wrote:
| I know this is mostly for Haskell, but I would add (used in
| various languages): e: event k: key in
| hash map, dictionary, etc. o: object or reflected object
| types v: value in hash map, dictionary, etc. t,
| u, v, w: vectors (borrowed from math)
|
| Would be fun to think about this for a while and come up with a
| more serious dictionary with examples and links to code.
| larodi wrote:
| How come are this specific for Haskell and not universal?
|
| My errors are caught as 'e', files are 'f', apparently indices
| are i, j, k, for as long as people been writing C.
|
| K/V are keys and values, and, well, 't' is time. I'm sure you
| can guess all other...
|
| I really don't understand how is this a specific language's
| thing.
| dvt wrote:
| > How come are this specific for Haskell and not universal?
|
| The author says as much. There's overlap for sure, but all
| the monad stuff, for one, is mostly Haskell-(or functional
| language rather)-specific.
| PaulHoule wrote:
| People used I,J,K,L for integers in FORTRAN and BASIC for
| that matter, in fact early FORTRAN determined the type based
| on the first letter of the name.
| jonathrg wrote:
| a is for array
|
| b is for byte or buffer
|
| c is for character
|
| d is for destination
|
| e is for event or error
|
| f is for file
|
| g is for graph
|
| h is for handle
|
| i is for index
|
| j is also for index
|
| k is for key
|
| l is for length
|
| m is for mode
|
| n is for number-of
|
| o is for object
|
| p is for part
|
| q is for queue or query
|
| r is for reader
|
| s is for source
|
| t is for time
|
| u is for user
|
| v is for value
|
| w is for word
|
| x is for x component
|
| y is for y component
|
| z is for z component
| yawnxyz wrote:
| js land: $: jQuery _: lodash, underscore
| libraries e: usually events like keyboard, button clicks,
| form submits, when preventing form actions...
|
| any other js quirks?
| o11c wrote:
| I don't Haskell, thankfully, but a lot of these are applicable
| broadly. Some notes/additions I've seen in other languages (but
| far more often these are obvious).
|
| (only vaguely sorted, since many aren't contiguous):
| a,b,c,d can be anything, but slightly more common for floats
| and/or coefficients, or matrices a is often "array" a
| can be ascii (either as string in general, or in specific)
| a can be "allocator" or "allocation" b for bytes is not
| shameful, but sometimes it means "buffer" or "bits" instead
| b can be "builder" (a utility class used to construct values
| instead of using "new" directly) c is often used for
| "character", "code unit", "codepoint"; ch/cu/cp can disambiguate
| c can also be "constant" (either a value or a modified type)
| c can also be "container" c can also be "condition" (a
| boolean) c can also be "context", but more often ctx or
| ctxt d is rarely used for "data", but more often it's
| expanded or v is used instead d can be "direction", but
| more often dir e can also be "event"; ev if needed e
| can also be "element" (member of an array, member of an XML-like
| tree) f is common for floats (even if called "double" or
| "real") or fixed-point numbers f is often file; fp/fo may
| be common depending on the language i can also be
| "instruction" i,o,r,w can be input/output i,j,k are
| common as indices *or* iterators, corresponding to x, y, z if
| meaningful. l is rare but can be a 4th index or iterator if
| needed, usually does not related to w though. l is probably
| more common as "length"/"limit" l,h can be low/high, but
| more often lo/hi n,+m are often specifically the upper
| bound of a range, similar to l o is an arbitrary object
| (usually, when explicitly not a primitive or string) o can
| be "origin" p,+q are not rare as "predicate" p,q can
| also be prime numbers p is for pointer q,r,n,d for
| fractions r (and rv/res) is sometimes used ambiguously -
| should it be the return value of a function I called, or the
| value I'm planning to return? r can be "range" r,c
| for row, column; origin is top-left and axes are flipped
| r,g,b,a are color components; other letters exist for other
| colorspaces s is often an arbitrary string s can also
| be symbol (sy/sym), statement (stmt), or set (often given a
| different kind of name) t for table t for time
| t,u,v (usually uppercase) are arbitrary types in generics v
| is often just an arbitrary data value (not meaningfully
| numeric/string/object), even without a container v,w,t,u
| can also mean "vector" specifically u,v,s,t,q are used for
| 2D texturing u can be unicode w can be wide
| character, but good riddance x,o,d,b can be hex, octal,
| decimal, or binary bases x,y,z,w are used for 3D objects; w
| is often normalized to 1 _ as a function or string affix
| means "call gettext on this now"; N_ means "remember to call it
| later" _,$ are sometimes injected as a general-utility
| global variable in languages with deficient standard libraries
|
| Mostly not mentioned, several of these are used uppercase for
| generic type arguments.
|
| I'm also ignoring all the various units and physical constants.
|
| I'm pretty sure about a dozen more passed through my head while
| writing this but I forgot them before I finished writing the
| previous entry, and I can't be bothered to actually start
| scanning code.
| w10-1 wrote:
| I agree with the semantics, but restrict usage to the very narrow
| case where the variable has no other use than to convey a value
| from a visible outer scope to a visible inner scope, where both
| together are less than a few lines. In that case I prefer the
| single character over a longer name precisely because it is
| clearer.
|
| Note that x,y,z don't really qualify as abbreviations since they
| are the full name of the component, so they can be used when the
| outer scope is not visible -- eg as a parameter.
___________________________________________________________________
(page generated 2024-10-13 22:00 UTC)