|
Ahhh, brings back memories, what you are experiencing now, and the grand daddy of them all, was called "Clippy" - The Twisted Life of Clippy[^]
After banning and exiling poor Clippy came all of the other tweaks (children if you like) to get you involved in NOT doing what you are suppose to but to pay attention to our "super hero geeky pop-ups" like...
[Got It]
|
|
|
|
|
I'm working on a react project that has a component and related components named filter, filter group, etc. They need a complete overhaul and I was told to create a new set of components so that we can slowly implement the new one. Now I'm having the mental dilemma of figuring out what to name these new components. I flat out refuse "NewFilter" or "FilterNew" because you know it's going to have another iteration one day..."Filter2" seems blah. Does everyone else fret over naming things? What would you pick?
|
|
|
|
|
|
Ha ha...I was looking at thesaurus entries. I was almost considering "sieve" just to be fun.
|
|
|
|
|
Another choice is translate.google.com
Put the component name on the left and go through various languages on the right, you have
filter
in Lithuanian is filtras
in Igbo it's nyo
in Scots Gaelic it's criathradh
now you have the benefit of learning new languages while you program
|
|
|
|
|
Chris Nicolatos wrote: in Lithuanian is filtras
in Igbo it's nyo
in Scots Gaelic it's criathradh
now you have the benefit of learning new languages while you program
What is it they say again about writing software as if the next guy that has to maintain it is a psychopath who knows your home address?
Yeah, that.
I don't see this as being any better than using random 2-character variable names. Or complete gobbledygook.
The smiley at the end of your post probably saved you.
|
|
|
|
|
Having grown up using FORTRAN IV where there was a 6 character limit to variable names using only A-Z and 0-9, you had to be very inventive to avoid everything being A1, A2, A3, I, J, K etc
|
|
|
|
|
I started off with Commodore 64 BASIC, where everything pretty much was A1, A2, A3, I, J, K.
You couldn't pay me to go back to that sort of thing.
|
|
|
|
|
I started out with "Real Time Basic" on a Univac 1100 mainframe; it was the that way. String variables were A$ through Z$.
"Real Time" because up until then (1975), Univac 1100 had run batch jobs only, submitted on punched cards. The Basic system was interactive (sort of...) through a Teletype with a 110 bps acoustic modem - Univac's first attempt at interactive time sharing. The machine did not make it through the acceptance test. Midway in the test period, it was discovered that Univac engineers had secretly doubled the amount of RAM to make it through the tests. The test was interrupted an a new test period started. It didn't go through that test round either, so the huge mainframe was returned to the manufacturer.
Later, in my student days, the brightest kid in my class was caught coding a rather large homework problems using variable names I00 to Inn (for integers), F00 to Fnn (for floats) and so on. We told him, "Prof. R.C. is going to blow up completely when he sees that!" But this classmate of ours was calm: "That's only while I am working at the problem. Before I hand it in, I will replace I00 with NumberOfApplesPerCase and F01 with AverageWeightPerApple and so on, but I can't bother to write such variable names while I am still working on it!"
Well, as I said, he was the brightest kid in the class. His brain had no problems associating I00 with the number of apples per case and F01 with the average weight per apple. He had no need for the mnemonic function of variable names.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Reminds me of the first Pascal tutorial book I read, where all of the variable names were Aztec gods, kings and priests, as the author reckoned they were about as readable and memorable as most programmers variables, and wanted to make the point that badly chosen variable names can obfuscate the meaning of the code.
|
|
|
|
|
Point taken, sheesh!
|
|
|
|
|
The textbook in my first university level course in discrete mathematics stated in the introduction:
If all rouve traths are slooth, and we have a rouve trath, then we know that the trath is also slooth.
We read the statement, grinned at the example, and nodded: Well, of course!
I guess it is more important in discrete math to learn the theorems and lemmas as generics, not bound to specific familiar concepts. Like, you learn to multiply 5 by 2 making 10, not 5 apples times 2 dollars a piece making 10 dollars. Well, that is a nice application, to understand why it is useful to learn 5 times 2. But if you learn from it how to multiply apples by a unit price, so you know nothing about how to multiply 5 km/h by 2 hours, because what you have learnt doesn't include speeds and times, then the 'meaningful' example with apples and unit price didn't help you at all.
You really should be able to learn a sorting algorithm, say, regardless of the kind of objects sorted. Or calculate an average. Or ... You should be able to calculate the average Āhuiatēteoh (*) value as well and as easily as the average AppleWeight value.
So, I will to some degree defend the choice made by that book. Not unconditionally - it may go too far. E.g. I think Knuth made a grave mistake in assuming that it doesn't matter at all which programming language is used to show the implementation of an algorithm, so a fictional assembly language MIX is as good as any other language. But to a certain degree, we must be able to abstract the idea conveyed by a code snippet, above the level of variable names - especially when accompanies by a tutorial explanation.
(*) The first entry in https://en.wikipedia.org/wiki/List_of_Aztec_gods_and_supernatural_beings
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Yes, it's a balance between the abstract and the concrete.
|
|
|
|
|
Many moons ago I worked on a project in need of a file record manager. We didn't have the resources to build it from scratch, and searched for a library. As we would have to make adaptations, we needed open source solutions.
We settled for one alternative recommended by several users - but it turned out to be useless to us: Every internal function, every variable, every comment was in French. None of us knew any French at all. We made a serious try to understand the workings of a few of the functions, but had to give up - it would be easier to write it from scratch ourselves (which had been ruled out for resource reasons).
Even long before that, I have in my code followed two rules: Everything that only a programmer will see is in English (including off line documentation). Anything that will be seen by a user, including the most advanced users, is in the language of the user (including all the online or offline documentation a user will ever see) - i.e. it may appear in multiple languages, so the texts should be organized for simple translation, in separate modules/files. So I never use Norwegian variable names in my code, even if the all the users of the program are Norwegians.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
|
Ha ha.. looks like "CharlesFilter" wins?
That site is pretty sweet. Might actually use it once I put together more options.
|
|
|
|
|
I love !!!
I am working on a image file viewer thingy using Windows Imaging Components. I was going to call it WinCodecBitmap, but after spinning the wheel I think I will call it Hanna.
Thanks
Within you lies the power for good - Use it!
|
|
|
|
|
That's brilliant. I'm going to use these in our standups, 'cause our current order is by volunteer.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
I clicked on the link because it would be a programming revelation
YES I am still learning no revelations here keep moving
I now know better humor is worth more than revelations
made me laugh Caught Covid yesterday so needed a laugh
Chris Maunder2
|
|
|
|
|
the dreaded 'vid. Salt water gargle and netflix. I hope it brushes you lightly.
cheers
Chris Maunder
|
|
|
|
|
I put together the two suggestions (M-W thesaurus and wheel of names). I pasted the list of related words in wheel of names and a clairvoyant spin produced the right answer: WASH. Like in: if you don't know what to name it, it's a wash; any name is as good as the next.
Mircea
|
|
|
|
|
Perfect task for Copilot.
I gave it the entire text of your original post and here is Copilot's response.
Copilot said: Ah, the eternal struggle of naming things in software development! It’s a challenge that many of us face, and it’s perfectly normal to fret over it. After all, a good name can make your code more readable and maintainable, while a poor one can lead to confusion and frustration.
Here are a few strategies you might consider when naming your new components:
Descriptive Names:
Aim for names that clearly convey the purpose or functionality of the component. For example:
FilterPanel: If your component handles filtering functionality.
FilterOptions: If it’s related to filter configuration.
FilterSelector: If it allows users to choose from different filters.
Think about what the component does and choose a name that reflects that.
Domain-Specific Terms:
Consider using terms from your project’s domain or industry. For instance:
TagCloud: If your component deals with tags.
SearchCriteria: If it represents search filters.
SortDropdown: If it handles sorting options.
Using domain-specific terms can make your code more intuitive for other developers.
Avoid Generic Names:
As you mentioned, names like “NewFilter” or “Filter2” aren’t very helpful. They lack specificity and might cause confusion down the road.
Instead, opt for more meaningful names that provide context.
Be Consistent:
If your existing components follow a certain naming convention (e.g., “FilterGroup”), try to maintain consistency.
Consistency makes it easier for developers to understand the relationships between components.
Avoid Abbreviations:
While abbreviations can save keystrokes, they often sacrifice clarity.
For example, prefer FilterConfiguration over FilterConfig.
Think About Future Iterations:
You’re right to consider future-proofing your names. Think about how the component might evolve.
Instead of “Filter2,” consider something like “AdvancedFilter” or “EnhancedFilter.”
Remember that there’s no one-size-fits-all answer, and different projects and teams have varying conventions. Ultimately, choose names that make sense in your specific context. And don’t worry—you’re not alone in this naming struggle! 😄
|
|
|
|
|
Filter2024
or
FilterTOS
FilterTNG
FilterDS9
FilterVGR
So old that I did my first coding in octal via switches on a DEC PDP 8
|
|
|
|
|
Yeah, I thought if there's no additional context beyond versioning a date works well (i.e. your `Filter2024` suggestion), as you shouldn't be refactoring multiple times per year, and keeping track of dates is easier than using any versioning system (e.g. if one component didn't get redefined when doing the v2 work, when you refactor again does that component jump straight to v3, or should it be the v2 of that component despite being v3 of the whole / etc).
|
|
|
|
|
FilterNew, Filter2, etc, as you put it, are bad options.
Try to add a bit of context to the name to differentiate it from other filters you may have elsewhere. What type of thing it's supposed to be filtering. If it's intended to filter items that all have the same interface (IBlob) or share a common base class (Blob), maybe BlobFilter. That sort of thing. Don't overthink it.
|
|
|
|
|