[HN Gopher] How Developers Choose Names
___________________________________________________________________
How Developers Choose Names
Author : matt_d
Score : 144 points
Date : 2021-04-18 12:46 UTC (10 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| zexodus wrote:
| Research like this could lead to IDE's suggesting names for some
| of our methods. Exciting!
| emodendroket wrote:
| Given how much it freaks the IDE out I can't imagine writing a
| method before naming it.
| spinny wrote:
| very badly, sometimes randomly, magic 8 ball
|
| would not be surprised if some dev somewhere considered naming
| his/hers first born "/tmp/first_born" until coming up with a
| better name
|
| we can also add mathematicians and physicists to the group of
| people that are exceptionaly bad at naming stuff
| Smaug123 wrote:
| Primo is an actual name in Italian; the others have fallen
| (more) out of fashion, but certainly Quintus, Septimus and so
| on used to be perfectly reasonable Latin names.
| adithyasrin wrote:
| Variable names are alright, available domain names are a
| different beast
| slver wrote:
| The more shared a name is, the greater the pain in selecting
| it. Given domain names are worldwide, no wonder then.
| ttiurani wrote:
| With naming what IMO matters more than choosing one name, is
| choosing a name that is consistent with other similar names in
| the codebase. A new developer will learn your project's specific
| convention in a few minutes, but will be completely lost if the
| convention is routinely violated here and there. This is
| especially important with what verbs to use in methods, and how
| to name interfaces/classes in a way that respects both the
| business domain and the techical use.
|
| I've seen way too many times how much confusion is created and
| time wasted when a developer not too familiar with the project
| comes up with a brand new verb for a common action, and couples
| it with a new synonym for an existing business domain entity - or
| worse still, uses the same name previously meant for a completely
| different domain entity.
|
| The unfortunate burden with this is that a new developer might be
| right that their name is better for their use case, which then
| leads to laboursome debates about which is more important:
| consistency or slightly crisper name for the one use case.
| hinkley wrote:
| You have to be careful with your definitions. Don't use
| different definitions of the same verb/noun in different
| places. You get one. If you need another definition elsewhere,
| use a synonym.
|
| It is not beneath you to hit thesaurus.com while picking a
| name.
| jeremydeanlakey wrote:
| A thesaurus is one of my favorite dev tools.
| archsurface wrote:
| Naming gets far worse than that. I've worked on code where the
| naming was not just unhelpful, it was outright misleading. One
| of the worst I remember was a project which unsurprisingly was
| named after a game of thrones character. As I never watched
| game of thrones it took me about two weeks before I could even
| remember the stupid name, during which time I was also
| dumbfounded as to how the program worked until I realised the
| naming in the code was equally bad, completely misleading. Then
| there's the place where the stg1 environment was actually the
| dev0 environment...
| saurik wrote:
| When I was working on a small game startup back 20 years ago,
| I renamed our all the high-level projects of our codebase
| into specifically- _ancient_ Greek and then left a
| "glossary.txt" in the root directory so people could brush up
| on their language skills... this did not last for very long
| ;P.
| wsc981 wrote:
| _> I 've worked on code where the naming was not just
| unhelpful, it was outright misleading._
|
| It's one way to achieve job security for life though:
| https://github.com/Droogans/unmaintainable-code
| dnautics wrote:
| One of the best coding interviews I had was an paired
| debugging session and the problem boiled down to a poorly
| named parameter at the beginning.
| scubbo wrote:
| > Then there's the place where the stg1 environment was
| actually the dev0 environment...
|
| Hey, think yourself lucky. It's only a pretty recent
| occurrence that my team has more than just the two "Prod" and
| "Non-Prod" environments...
| aYsY4dDQ2NrcNzA wrote:
| Using the name "prod" for anything other than delivering
| code to external customers is one of my eternal pet peeves.
| vas1 wrote:
| Couldn't agree more with this. Consistency is key even if the
| convention used is awkward
| jariel wrote:
| Yes, convention is more important that the quality of the
| convention. The convention abnegates the need to think about
| things, and for a developer, thoughts are precious.
| PicassoCTs wrote:
| With a good convention, even more important, structure can be
| derived and deduced, without reading the documentation. I
| love it, when i begin to grasp the structure of a codebase,
| write a line and hit auto-complete and the codebase was
| reliable. Functionname exists and parameters expected are
| served up. The code just feels so much more discover-able in
| such moments.
| jawns wrote:
| This goes double for APIs, and triple for externally facing
| APIs, where typically the people who are working with it aren't
| familiar with your code base or naming conventions.
|
| That's why good API design is so hard. Every name you assign to
| something becomes a convention by default.
| cconroy wrote:
| oh man; they should of selected 42 or 1337 study subjects!
| makach wrote:
| This reminds me of this old quote from qotd: We had fairly random
| naming for our servers, so I proposed we named them after planets
| - and the admin responded with "great idea, you mean like
| planet01, planet02, planet03.."
|
| It's a funny story, but naming means ALOT when you are
| developing, or building systems or processes that requires a name
| or an identificator.
|
| Also don't be afraid of changing the name if it no longer
| reflects on its purpose.
| swyx wrote:
| sharing a relevant bit of research I did collecting naming
| practices across a bunch of different languages and frameworks:
| https://www.swyx.io/how-to-name-things/
| granshaw wrote:
| I have a rule called "name it what it does, not how it's used"
| which is a mistake I often see with junior developers and
| sacrifices information density
|
| Eg it's more helpful for readability to do "onClick =>
| updateDate()" rather than "onClick => handleClick()"
|
| (Not the best example and I've seen far more egregious, but those
| examples are escaping me now)
| rickbad68 wrote:
| This example is not good for talking about naming as there is
| no proper design which would have a function like this. In any
| proper design there would always be a separate function for
| each of the concerns.
| bryanrasmussen wrote:
| the benefit for handleClick in a react codebase at least is,
| aside from convention, generally there will only be one click
| action per component and then you can see right when you come
| into the component - hey there is a click somewhere in this
| component.
|
| In that case what I find preferable is onClick => handleClick()
|
| handleClick = () => { stuff in handle click updateDate(); }
|
| on edit: I see lots of others made same point one node lower.
| dexwiz wrote:
| I completely disagree with this example. Only in first order
| implementations does that click just change the date. As you
| refine UX you may add some debounce, error handling,
| alternative behavior, etc. DOM events rarely end up
| corresponding to such simply expressed handlers.
|
| Also when you are reading the reverse, it's not clear on what
| on what updates date. The worst scenario is when two listeners
| share a handler.
| irrational wrote:
| What are your naming recommendations?
| dexwiz wrote:
| Exactly what OP discourages. Ha dleClick for onClick,
| handleDragOver for onDragOver, etc.
| echelon wrote:
| These are both pretty bad if used non-locally across files.
| Maybe it's a bad habit from Java, but verbosity helps a lot,
|
| updateDateCallback()
|
| updateDateFromClick()
|
| These show how it's used and what it's doing.
|
| (actually, "up-date date" kind of irks me,)
|
| handleDateChangeClick()
|
| dateChangeModalClickEvent()
|
| And what does this thing actually do? Is it updating data, or
| making the update UI visible? It's kind of unclear.
|
| If you're showing/hiding UI rather than performing the model
| update,
|
| showChangeDate[Field/Modal/...]()
|
| beginChangeDateFlow()
|
| ...
|
| Code should read kind of like a book.
| 3grdlurker wrote:
| I'm an engineering lead and I made a rule of using the
| handleClick() style instead of updateDate() in our codebase.
| The reasoning is that the latter sounds more like an atomic,
| standalone function, whereas handleClick() may have some
| internal checks that could eventually call something like
| updateDate(), but the internal checks are beyond the
| responsibility of the updateDate() function.
| granshaw wrote:
| Yes my example was if updateDate literally just updates the
| date - I take this a step further too, Eg if the function has
| some extra checks, I'll name it maybeDoX(), which is a
| somewhat uncommon practice in common programming languages
| [deleted]
| city41 wrote:
| I agree. It's also nice to know when you see a `handle`
| function, it is getting slotted into an `on` somewhere.
| Within the handle I prefer to call functions such as
| updateDate().
|
| But this whole thread brings up something about coding that
| has always irked me, it's very opinion based. When two people
| strongly hold the opposite opinions on the same team, it can
| be a massive hassle for absolutely zero benefit.
| nitrogen wrote:
| _When two people strongly hold the opposite opinions on the
| same team, it can be a massive hassle for absolutely zero
| benefit._
|
| On teams, or in life in general, IMO when there is no
| consensus, or even an anti-consensus, the only rational
| global decision is not to make a global decision.
| hinkley wrote:
| It also quickly explains to you that no, you can't refactor
| this method to change the arguments.
| DrSiemer wrote:
| In training interns I had to figure out what part of my
| coding advice to them is best practice and what part is
| just the way I like to do things.
|
| It's good to know the difference and it gave them the space
| to challenge me on some of those methods, which in turn
| helped me write better code.
| hanniabu wrote:
| Personally I would have both and within the handleClick()
| function do whatever it needs to do and call an atomic
| updateDate() function (assuming it's updating the date
| globally). Although for anything generalized standalone
| function I like to put that in its own namespace, such as
| helper.updateDate().
| dapids wrote:
| Or be explicit. Call it AtomicUpdateDate if such
| functionality is really desired. Nobody should assume any
| operation is atomic ... Unless it is explicitly stated to
| be so.
|
| EDIT: sorry meant to reply to the parent comment.
| jbluepolarbear wrote:
| I take this approach as well; especially, when the handle
| takes an event param and can then let the object react with
| the correct behaviour.
| throwawayboise wrote:
| validateAndUpdateDate()
| TechBro8615 wrote:
| > may have some internal checks that could eventually call
| something like updateDate
|
| This sounds like exactly the kind of pre-mature optimization
| that leads to overly-abstract function names throughout the
| codebase. Your point is a good one, _once the function does
| something more than `updateDate()`_. But until then, just
| call it `updateDate()`. As a bonus, this way any time you
| _do_ choose to use `handleClick()`, the name is conspicuous
| enough that you pause to see what side effects it might have.
| rileymat2 wrote:
| I'd agree in some cases, but then you get weird debouncing code
| in your update date function. Because, no one wanted to change
| the onClick function name in 38 different places when it starts
| to do more.
| Forge36 wrote:
| onClick => onAccept => submitRequest
|
| The downside is lots of little functions, the plus side is
| smaller behaviors. (Ie avoiding 5 levels of nesting in a
| single function.)
| MattRix wrote:
| This sort of thinking leads to codebases that are too
| abstract, where it's hard to follow the flow of execution.
|
| There's nothing wrong with 5 levels of nesting. It's much
| easier to follow than 5 separate functions.
| hallway_monitor wrote:
| If you don't have refactoring that can rename functions
| across your code base, now you have two problems
| rileymat2 wrote:
| In 16 years as a developer, I have never seen this beyond
| the scope of a single project/language. Once things cross
| boundaries it stops.
| marshmellman wrote:
| What boundary would be involved in the handleClick
| example? Or are you speaking more generally about renames
| across API contracts?
| rileymat2 wrote:
| Here is a great example that came up last week. Almost
| exactly like the OP. (It is even an onclick!)
|
| I have a C# .net asp project. All of the JS, .cshtml
| templates and C# controllers are in the same visual
| studio solution. So it has complete vision into the code.
|
| So the boundary is from cshtml template to javascript
| function and then another one from the ajax call to C#
| controller.
|
| Visual studio has complete vision, but loses the
| connection at each boundary, so intellisense says that
| the C# controller function is never called.
|
| I am not criticizing Visual Studio, it is a great tool,
| but this is a hard problem.
| [deleted]
| dividedbyzero wrote:
| Even within those bounds, I found it doesn't always work
| terribly well (depending on the language, tooling and
| project complexity)
| echelon wrote:
| I've hit this many times.
|
| Microservices and JSON APIs.
|
| Common library code (eg. common session handling)
| incorporated into dozens of microservices.
|
| Monorepos (which actually make this problem somewhat
| easier).
| katzgrau wrote:
| Agreed, and something to add in the explanation of what to do
| is the "why."
|
| When someone (or you) is reading the code later, you see a
| method call and know exactly what it does. This prevents you
| from having to click in or find it just to figure out what it
| does.
|
| Frequently, if you click into a vaguely named method, it
| doesn't do the thing you were searching for and you wasted a
| little time and need to backtrack, only to repeat the cycle
| with other vaguely named methods.
| ape4 wrote:
| But how its used is often inseparable from what it does. And in
| UI code its nice to have all user actions called OnXxx or some
| convention.
| username90 wrote:
| That is all well and good, until you have many components all
| needing to handle clicks. Then it is better to do a handleClick
| abstraction and put the updateDate inside it.
| bitwarrior wrote:
| It entirely depends on what the function is receiving.
|
| In your example, assuming we're looking at a React codebase
| (since this seems to square with React's style of events, etc),
| the resulting data being set into the updateDate function would
| be an event.
|
| This, unfortunately, doesn't make any sense for a function by
| the name of updateDate to receive. I would expect to receive at
| least a new date to update with in the parameters, or ideally
| in a functional world, both the state to update and the new
| date we want applied to it. Anyone thinking they could simply
| reuse the updateDate function somewhere else is going to be
| woefully disappointed they largely cannot, since it would have
| been constructed around receiving an Event object.
|
| In that case, I find the "handle" nomenclature to be very
| useful, as it appears to be largely shorthand for functions
| design to handle an _event_ (and we tend to see this pattern
| being used in various React libraries and documentation). React
| does have a few of these shorthands it tends to use (such as
| useEffect largely being short for useSideEffect).
|
| Ultimately, I recommend using both functions. One, a
| handleClickUpdateDate function (notably _not_ a hyper-generic
| handleClick function which conveys nothing) that receives the
| event and pulls out the necessary information out of that event
| to determine what the date is that the user has selected. It
| then will call the updateDate function with only that date,
| which creates a nice, reusable updateDate function if we need
| it anywhere else.
|
| This roughly squares with the idea of having functions that
| handle the data transport layer (such as receiving data via
| HTTP or gRPC, etc) whose responsibility it is to receive those
| events, pull out the necessary information out of the package,
| route the request to the correct controller, and ultimately
| return the result in a shape that satisfies the original
| transport mechanism. In this case, our handle* function is
| responsible for receiving the original transport of data, then
| routes the request through to the appropriate controller which
| is entirely unaware of the means of data transport.
|
| It also means we have a nice, easily testable unit of
| updateDate to verify our state modification is working to our
| liking without needing to assemble an entire Event object.
|
| Anyhow, that's how I think of these things ;p
| tcbawo wrote:
| I completely agree with this, but I additionally advocate for
| function/method names to be formed verb-object. Plus IMHO
| active, descriptive verbs are best, instead of 'do', 'handle',
| or 'manage'. As others have mentioned, handle click might be
| appropriate as a shim/landing point for satisfying an
| interface. Logic is best when focused without unnecessary
| dependencies/side effects. The best naming comes along with a
| strong design and architecture, when all the pieces can justify
| their existence and boil down to the essence of what the system
| is trying to accomplish.
| rickbad68 wrote:
| This seems such a weird study. Names are important, but not so
| much as what is being named. In one sense, names become easy
| given a properly abstracted design. Further, it's not names so
| much that are paramount to program comprehension, but more the
| quality of the design. With a bad design that doesn't properly
| separate concerns it won't be possible to come up with good names
| because functions/data structures will represent multiple
| concerns. Any time names are controversial it probably indicates
| a design problem, even for unique/complex abstractions, there is
| usually a name which everyone agrees is the perfect name for a
| thing..
| johnchristopher wrote:
| As a non native english speaker I have a recurring problem with
| this:
|
| > getInstances(); // ok, returns an array of instances
|
| > getInstanceId(); // ok, returns an id
|
| > getInstancesId(); // ??, returns an array of id
|
| > get InstancesIds(); // ?? returns an array of id
|
| > getIdsOfInstances(); // ?? returns an array of id
|
| > getAllInstancesId(); // ?? returns an array of id
|
| > getAllInstancesIds(); // ?? returns an array of id
|
| How do I conjugate that ? And what about the possessive `s` ?
| crazygringo wrote:
| As a native English speaker (and former English teacher), hope
| this helps:
|
| > _getInstances(); // ok, returns an array of instances_
|
| Correct.
|
| > _getInstanceId(); // ok, returns an id_
|
| Correct.
|
| > _getInstancesId(); // ??, returns an array of id_
|
| Unusual, but would return a single ID referring to a collection
| of instances.
|
| > _get InstancesIds(); // ?? returns an array of id_
|
| Correct.
|
| Though more common would be getInstanceIds() since you don't
| need to pluralize twice. E.g. we don't say "blues shoes", we
| say "blue shoes", so these aren't "instances ID's" but
| "instance ID's".
|
| However, in naming functions or variables you'll sometimes see
| plurals repeated for clarity. E.g. getInstanceIds() is
| ambiguous because it could refer to the ID's of multiple
| instances, or multiple ID's of the same instance. While
| getInstancesIds() makes it clearer that it's the ID's of
| multiple instances, even though it's not actually grammatically
| correct.
|
| > _getIdsOfInstances(); // ?? returns an array of id_
|
| Same as getInstanceIds(). Both are correct, though
| getInstanceIds() would probably be more common -- most people
| wouldn't put in the extra word "of" simply because it's an
| extra word, but sometimes it might be clearer for consistency
| with other function names.
|
| > _getAllInstancesId(); // ?? returns an array of id_
|
| It would mean the ID for the collection of all instances,
| though that would seem very unusual. Perhaps if there were a
| global account ID for a service or API you used.
|
| > _getAllInstancesIds(); // ?? returns an array of id_
|
| Sams as getInstanceIds(), but "All" presumably means it doesn't
| include a parameter to filter -- so I'd assume this implied the
| existence of another function such as
| getCollectionInstanceIds() or similar that it was contrasted
| against.
|
| > _How do I conjugate that ? And what about the possessive
| `s`?_
|
| Obviously you can't or shouldn't use apostrophes in variable
| names, so people generally try to avoid the possessive s.
| That's why we generally change nouns to noun adjectives --
| instead of "computer's ID" (computer = noun) we use "computer
| ID" (computer = noun adjective).
| pcthrowaway wrote:
| > Though more common would be getInstanceIds() since you
| don't need to pluralize twice. E.g. we don't say "blues
| shoes", we say "blue shoes", so these aren't "instances ID's"
| but "instance ID's".
|
| Completely agree with all your points (as a native English
| speaker who also minored in English)
|
| However, for the sake of clarity (since we're trying to
| disambiguate between places the 's' could indicated
| possession vs. plurality) "instance IDs" should not have an
| apostrophe.
|
| The only time an apostrophe goes in a non-possessive plural
| is in a contraction. E.g. "the '90s"
|
| Then we also have fun words that probably should never be
| used which get an apostrophe on both ends (contraction at
| beginning + possessive plural)
|
| e.g. " ... the '60s' countercultural attitudes ..."
|
| But for clarity it might be better to go with
|
| "... the countercultural attitudes of the '60s ..."
| crazygringo wrote:
| That's a hotly debated issue that different style guides
| give different answers to.
|
| Some style guides insist plural all-capital abbreviations
| should never have an apostrophe ("IDs"), other insist they
| should ("ID's").
|
| Your personal usage is absolutely valid, but it should be
| recognized as opinion and not fact. "ID's" is equally valid
| in modern usage.
|
| Edit: You can read an extensive discussion of it here:
|
| https://en.wikipedia.org/wiki/Acronym#Representing_plurals_
| a...
| pcthrowaway wrote:
| Interesting. I've seen the apostrophe for acronyms which
| involve periods: e.g. "C.D.'s" (NYT has an article about
| this being their preferred style)
|
| I've seen it for one-letter words where you don't want to
| switch case: e.g. "dot your i's and cross your t's"
|
| But I haven't seen it in upper-cased abbreviations
| followed by a lower case plural 's'. Or if I have, I've
| assumed it's wrong. Would love it if you can refer me to
| a modern style guide which doesn't recommend dropping the
| `'` in this usage, as my own background has drilled into
| me that "IDs" is preferred for clarity.
| crazygringo wrote:
| I just added a link to a Wikipedia discussion in my
| comment above, which should answer your question. It
| gives an example:
|
| > _...whereas The New York Times Manual of Style and
| Usage requires an apostrophe when pluralizing all
| abbreviations regardless of periods (preferring "PC's,
| TV's and VCR's")._
| samatman wrote:
| I would make a case that _in our field_ , one which has
| an abundance of initialisms and non-period-separated
| acronyms, we shouldn't shadow the possessive. Consider
| "this script retrieves JSONs from all API URLs and
| validates them against their respective schemas" and
| "this function extracts the URL's fragment, if any, and
| checks it against a set of page targets". If you use an
| apostrophetic plural, does the latter receive one URL, or
| a collection of them?
|
| URL was carefully chosen, since you can't make a
| consistent ruling about initialism vs. acronym, I've
| worked with people who pronounce it "you are ell" and
| people who say "earl", and sometimes both! Absolutely no
| one is going to start spelling it U.R.L., either.
|
| Especially given the abundance of non-native speakers,
| let's not add a peculiar and ambiguous edge case to one
| of the more frustrating rules of English grammar.
| crazygringo wrote:
| I'm intrigued, but I'll admit entirely confused, by your
| comment.
|
| First, I don't know what it means to "shadow" the
| possessive. Do you mean we shouldn't hide it? Although it
| always has an apostrophe so we're never hiding it.
|
| Second, I don't understand your examples. Your second
| example clearly necessarily uses the possessive, while
| the first is a plural, but the first would clearly be
| plural even with an apostrophe:
|
| > _" this script retrieves JSON's from all API URL's"_
|
| And since a possessive necessarily precedes another noun
| in this type of construction, it would still be clear:
|
| > _" this script retrieves JSON's from all of the API's
| URL's"_
|
| It's clear in speech and clear as written, even though
| the "'s" serves two grammatical purposes here.
| repsilat wrote:
| One thing that _getInstancesIds()_ might mean is "get the
| (multiple) ids for each of multiple instances".
|
| I don't know why an instance would have more than one id,
| probably more plausible with different nouns, but a similarly
| named function might return an array of arrays, or a
| flattened equivalent, possibly uniqued.
|
| Probably a bad idea though. I have been guilty (though
| pleasurably, pridefully guilty) of abusing plurals -- day,
| days, dayses etc. If you can let the types do the talking
| that's obviously better, and more descriptive (and less
| eccentric) names can help a lot with communication and
| clarity, but there is also sometimes a place for brevity, and
| for levity.
| johnchristopher wrote:
| Thanks everyone, much appreciated :).
| halfmatthalfcat wrote:
| getInstanceIds
| augustk wrote:
| I have never understood the practice of using a verb phrase
| ("get") for functions with no side-effects. To me it makes more
| sense to name the function after the result, i.e. _Instances_ ,
| _InstanceIds_ , _AllInstanceIds_ etc.
| codr7 wrote:
| The advice I once got and since internalized is to reserve
| 'getX' to give a hint that something happens besides
| returning 'X', lazy initialization is a common use case.
| halfmatthalfcat wrote:
| Preforming I/O is a side effect. Accessing an external
| database is a side effect. Using a verb to imply external
| access to "get" some resource is appropriate in this
| instance.
| resonantjacket5 wrote:
| getInstancesId() would usually mean a singular id corresponding
| to the group of instances.
|
| Only ones with an "s" at the end of the id should return an
| array if you have the existing "getInstanceId" either that or
| invert that function to be getIdOfInstance and subsequently
| getAllIdsOfInstance for the array version.
|
| Generally speaking don't use the possessive "s" it is implied
| by being next to it. Also I usually use "instance" in this case
| more like an adjective
|
| Edit: usually I think of it as (current subject) verb adjective
| object.
|
| So server get instance IDs becomes getInstanceIds() or zoo
| clean active dogs becomes cleanActiveDogs()
| slver wrote:
| One of the most cruel things evolution did to us is that we
| constantly seek meaning, order, correctness, where there are none
| to speak of.
| cbcoutinho wrote:
| I'd argue that the ability to unite people by assigning meaning
| onto things, places, and ideas is the single reason why humans
| have been so successful in advancing civilization to where it
| is today.
|
| Edit: eschew -> assign
| papito wrote:
| Sure, but now it's actually DE-volving our society in form of
| QAnon and religious "interpretations", and technology here is
| not blameless in the least.
| selfsimilar wrote:
| Pedant note: eschew means 'to go without'. You probably meant
| 'assigning'.
| cbcoutinho wrote:
| Whoops, thanks
| slver wrote:
| That's precisely the problem. It's very useful, when it's
| useful. Which leaves us spinning in circles when it's not.
| 3grdlurker wrote:
| It would be impossible for you to say this (circular)
| sentence and call something a "problem" if you didn't think
| that there was some basis of right/wrong, which contradicts
| your top-level comment.
| slver wrote:
| See, this shouldn't cause a deep sorrowful void within
| me, but it does.
| coliveira wrote:
| Well, with the internet we don't need to do it anymore.
| Everyone has lost the battle to organize the internet, and it
| is now the helm of run away AI algorithms. And the same is
| happening to other areas which are controlled by AI and "big
| data".
| 3grdlurker wrote:
| That awfully sounds anti-knowledge. Humans didn't use to think
| that there was an order or correctness to all the facts that
| fall under science and mathematics today.
| dudeman13 wrote:
| How do you know that there isn't meaning, order and correctness
| if you don't search for it?
|
| There are very few situations where you can definitely say that
| there isn't meaning, order and correctness as opposed to not
| knowing if you are just too dumb to find them.
| rileymat2 wrote:
| > Based on the results of this experiment we developed a 3-step
| model of how names are constructed: (1) selecting the concepts to
| include in the name, (2) choosing the words to represent each
| concept, and (3) creating a name from these words.
|
| This seems flawed, when I look to name something, one of the most
| key things is what other things are named in that context, and
| patterns and consistency between them.
|
| It appears the study described a problem, instead of putting them
| in preexisting code?
| karmakaze wrote:
| This is a actually the way I name important things. There's
| even a 4th step: Choose only a few of the important or
| distinguishing concepts to include in the name. For examples in
| a database model you end up with x_y_z_name_id because of
| relations on relations, that might get reduced to y_z_name or
| x_z_name, dropping the part that is of widest/implicit context.
| jariel wrote:
| This is one of the most interesting artifacts of programming, and
| it's probably impossible to explain to people outside the field.
| How at the same time it's trivial and important, and a constant
| cause of neuroticism.
|
| It takes up far too much tought-space to the point I would gladly
| follow some ugly set of conventions merely to have to just never
| think about it.
| hallway_monitor wrote:
| Sure, following some guidelines and standards is helpful. But
| never having to think about naming is almost like never having
| to think about logic. What you name things dictates how future
| developers think about them. Just this week we had a feature
| that could belong in an existing module or it could require a
| new module all depending on how we define the domain and
| therefore the name of the existing module.
| jariel wrote:
| "s almost like never having to think about logic. "
|
| Not really, because naming is 98% convention when it's done
| right.
|
| The challenge is establishing all the conventions for a
| project, and then sticking to them.
|
| If there are really good conventions in place, well known,
| then naming is considerably easier.
|
| In fact, even if the conventions are not super good - they
| can be powerful when they are very well adhered to.
|
| Example: recently broke a rule and decided to use a known
| naming anti-pattern by suffixing variable names with the
| system type. This is normally not good. But within this
| module, the meta typing was ambiguous - by adding the suffix,
| the code was magically more clear. That little convention,
| very easy to apply, solved a clarity problem far more so than
| any issues around what functions should be called. So we used
| it for the module and that module only.
|
| Apple has some pretty hardcore naming conventions that I
| don't really like, but what's more important then whether
| they are good or not, is that they are very consistently
| applied - in other words - a lot less to think about.
| anonu wrote:
| I find that I am remarkably internally consistent with how I name
| things. I sometimes forget about a filename, class or function
| that I wrote months ago (thats another problem in itself). But
| when I go to name the new thing I am about to write I realize
| that it already exists. I then pat myself on the back.
| nicetryguy wrote:
| I thought you just added "ly" and called it a day?
| bitwize wrote:
| You watch your program buzz,
|
| But don't know what anything does.
|
| How do you name things so they're obvious to the eye?
|
| Descriptively,
|
| descriptively,
|
| descriptive... L-Y!
| amelius wrote:
| Say what you want, but it's better than how mathematicians choose
| names imho.
| thom wrote:
| I would be interested if any task-performance based studies had
| been run with different naming schemes and enough developers to
| see which naming conventions worked best. Some simple job like
| fixing a bug or a simple refactoring, judged on time to
| completion and correctness.
| hallway_monitor wrote:
| That would be great empirical data to see. However from
| anecdotal data across almost two decades, is extremely obvious
| to my case study that naming is second only to application
| architecture in its impact on ease or difficulty and risk of
| updating the code base in the future.
| baby_wipe wrote:
| My process:
|
| (1) How would I explain face-to-face what this code does to
| another developer?
|
| (2) Use the key words from that explanation to make a name as
| short as possible without losing clarity.
|
| Example:
|
| Step 1: This class handles all the navigation work for the sign-
| up flow in our mobile app.
|
| Step 2: SignUpFlowNavigator
| loloquwowndueo wrote:
| Naming things - one of the four hardest problems in computing
| (the others are sorting and off-by-one errors) :)
| ravenstine wrote:
| Don't forget time comparison.
|
| Your unit test of a function comparing dates relies on server
| time and usually fails if run around 12pm. Whatever. Nobody
| uses this app around lunch time anyway. Just tell your
| teammates in the to ignore that. Wait, why is the test failing
| every time today?! Did we just switch to DST? Uh oh...
| papito wrote:
| This has to come with a trigger warning.
| fiddlerwoaroof wrote:
| "Our JavaScript date library and the date library we're using
| in Clojure disagree on the first day of the week.
| Elasticsearch disagrees with both too"
| emodendroket wrote:
| You can avoid this problem by always passing in either a time
| or a time provider and never just relying on Time.now or
| whatever it is your language provides.
| fiddlerwoaroof wrote:
| This. Nearly every date/time library comes with this sort
| of attractive nuisance that is just waiting for a chance to
| ruin your day.
| mnutt wrote:
| I recently came across a 15 year old bug in qt involving both
| time comparison _and_ cache invalidation: the code was trying
| to set timers to fire when the next cache entry was set to
| expire, but the timeout was in seconds while the eviction
| code compared milliseconds. The result was 100% cpu usage for
| up to a second as the timer spun without evicting the cache
| entry.
| neilparikh wrote:
| Funny related story: For an internship, I worked on a app
| that would show your sleep data in a nice visualization (this
| was for a smartwatch). I implemented a basic version, and
| used it for a few weeks. It seemed to work fine for me, so I
| released a beta version for others in the company to dog
| food.
|
| Within a day, I got a bug report from a coworker that it
| rendered incorrectly for them. I was pretty surprised, since
| I had been using it for a long enough that I would have
| expected to encounter all the edge cases.
|
| I dug into the code, and realized that this bug only happened
| if you went to sleep before midnight, which I never did...
| gavinflud wrote:
| Funnily enough, I recently had to help with an issue where a
| company's payment screen was not loading correctly and
| instead displaying "Invalid session". They use a third-party
| vendor to handle payments and display their payment form in
| an iFrame on their website.
|
| There is an initial request to create a session that has to
| pass the desired expiration time of the session.
| Unfortunately, the vendor requires the time to be in Eastern
| Time. The poor, naive soul that originally implemented this
| just got the current date, added 15 minutes, and converted it
| to "EST". As soon as daylight savings hit a few weeks ago,
| the expiration time was automatically being set to 45 minutes
| in the past, the vendor was responding with "Invalid Session"
| and the company was unable to take payments from customers.
| netflixandkill wrote:
| Discussions about naming schemes make me think of the old joke
| "until I got married, I had no idea there was a wrong way to
| boil water" or other variations of banal tasks :)
|
| Perhaps there is an answer lurking out there in the universe,
| but it feels more likely it'll only be invalid pointer Aborted
| (core dumped)
| jwdunne wrote:
| Looks like you need to invalidate your cache of hardest
| problems in computing ;)
| amelius wrote:
| Proper caching makes any problem 10x as hard.
| athrowaway3z wrote:
| Twice as hard is a underestimate imo.
| GuB-42 wrote:
| Twice as hard? Or is it three times?
|
| Like they say, there are 10 kinds of people, those who
| understand ternary, those who don't, and those who
| mistake it for binary.
| froh wrote:
| five... naming, sorting, of by one concurrency errors and.
| fiddlerwoaroof wrote:
| I see a transaction rolled back, and the autoincrement id
| column no longer matches the row count.
| mod wrote:
| Well, the app is broken now because we relied on the
| autoincrement id column never having a missing value and
| didn't handle the error when it has one missing.
| mmmd wrote:
| Honorary mention: Copy/Pass by reference or value
| karmakaze wrote:
| Sorting actually isn't one, at least anymore. Exact once and
| in-order delivery although part of 'distributed' computing
| should be, since most computing is distributed, right down to
| our multicore processing hardware.
| loloquwowndueo wrote:
| It is - do your sorting, then show the results to
| stakeholders and you'll see they all want different, mutually
| conflicting sort orders.
| ed25519FUUU wrote:
| How about numbering? I always use to get a sideways glance back
| in the day (before we all started using uuids) when starting the
| number for a server group at 0. You'll only have 9 servers in the
| first group and 10 thereafter if you start at 1! Yet some people
| insisted.
| dw-im-here wrote:
| Says in the paper they had 337 subjects, so we'll have to match
| them with 337 irrelevant anecdotes so that we too can be
| scientists
| nuclearnice1 wrote:
| "But choosing good meaningful names is hard. We perform a
| sequence of experiments in which a total of *334 subjects* are
| required to choose names in given programming scenarios."
| anon_tor_12345 wrote:
| you think that's bad? this paper
|
| http://pdinda.org/Papers/ipdps18.pdf
|
| surveyed ~150 and concluded therefrom. the more hilarious thing
| being that they drew conclusion completely unscientifically
| i.e. by just interpreting vague plots (i.e. without performing
| t-tests or anything like that).
| [deleted]
| efortis wrote:
| In this video [1] the developer uses the prefix *old* where I
| normally used *prev*. Today I renamed all those "previous in
| time" to "old" for distinguishing them from the previous or next
| of a list.
|
| [1] https://youtu.be/AQ0lcm2_skI?t=319
___________________________________________________________________
(page generated 2021-04-18 23:01 UTC)