|
Yeah that's the one 
|
|
|
|
|
May I inquire how you were lead to the solution Every list of synonyms I traveled did not provide it I am assuming it was as new to you as it is to me Do you have software which generates anagrams and checks their definitions - Cheerio
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
|
|
|
|
|
To be honest, I don't have a clue: my head is stuffed with useless sh*t that springs up when I need it. Mostly to annoy people in Trivial Pursuit games ... 
Probably, it came up in a crossword, a book, a scramble game, or somewhere else equally random at some point and I looked it up to find out what the heck it meant.
Anagrams aren't that difficult - they generally leap out at me, or I write them down in a "cloud" and see if anything connects.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
The approach I take when I am fairly sure there's an anagram is just to examine the letters. Here the clue ("blemishes") is plural, so it's a fair starting point to assume the word may end in s. There's no e so, unlike blemishes, it's not es at the end so we've now simplified it to a 10-letter anagram. We've got all the letters t, i, o and n so there's a good chance it ends "tions". Great, now we just have a 6-letter anagram to solve. At this point I write down the 6 letters in a random pattern (not all on one line) and just gaze at the centre of the group. I'm not "reading" the letters, just looking at them as a group (or a cloud as Griff has better termed it). Sometimes this works and the word "pops out", sometimes not. If not, with 6 letters, it's not too hard to just start trying sequences that would be pronounceable. In this case, I can fairly readily spot the combination "macula" which I associate with macular degeneration, a particular type of sight loss. I don't know exactly what causes it, but a quick search on "macular" tells me it's (1) a small spot or (2) a small discoloured spot or blemish. Put the two together, MACULATIONS. Look that up to verify. (At this point the definition tells me maculations also refers to the pattern of spots or markings on an animal or plant, and at that point I remember it's a word I've come across before anyway, and now I understand its derivation!)
In short, look for likely patterns from the letters you have, then shake up the leftovers until they sound likely, then verify. I've been out today so haven't looked at the clue till this evening, but I suspect I'd have got there...
|
|
|
|
|
Well said Derek
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Further to my earlier reply about anagrams, it's finally dawned on me (whilst in the shower) that the word immaculate simply means "without maculations"... so not as rare a word (root) as you might think!
As in 2nd level support: "No sir, that's not a bug; it's a maculation of the code".
|
|
|
|
|
ok, sometimes there are very good comments...
but every time the reviews are waaaaay too slow. and very often there are comments which are both useless, antagonistic and a big waste of time...
for example I don't see the point of long variable name nor do I like them, particularly for a short liner like
double Value
{
get
{
var x = Calculation();
return flag ? x : 2 * x;
}
}
And have to wait a few more hours because I was told 'not to use short variable name'.
Unsure I renamed 'x' to 'aNumber', but that irks me...
On top of that, that might be just me with my bad memory, but I find long variable name harder to read! 
For example a simple expression like a = b + c
can confuse me if you write instead myobjectBlu = aCycleValueOrdinal + meteorStrikeOffsetTime.
Why they not care about making the code easier to understand?! 
ok, ok, I need to get over it. just venting here! 
Joke aside, you might like long variable name, but you won't convince me. save everyone's time and let's just agree to disagree. Or disagree to disagree, if you prefer...
EDIT
Upon reflection, I might be part of a minority of people with reading disability..
When reading long sentence I am skipping words and filling in by guess. Similarly long line of C# requires me multiple reading. And it kind of depends on the overall number of character, not words...
So I guess normal people comes with their usually suck it up, I am fine... 
modified 7-Sep-21 2:40am.
|
|
|
|
|
double Value
{
get
{
var x = Calculation();
return flag ? x : 2 * x;
}
}
Uugh. Why not something easier to understand?
double IdiotSize
{
get
{
var size = CalcSize();
return notDoubledFlag? size : 2 * size;
}
}Or whatever the domain really is?
|
|
|
|
|
so we disagree to disagree then?
I find the later no easier.. In fact some interesting brain chemistry must be at work here...
I was reflecting how physicist (that's my background), prefer short name too, i.e. it'e E=mc^2, not Energy = Mass * SpeedOfLight^2, to vindicate me...
Anyway, regardless, it's more interesting to consider what psychological factor lead from one to another.
I know that for me, bad work memory favor short variable names. Long variable names are just too hard, I have to read the statement 2 or 3 times to get it.
1 or 2 time to get all the variables involved, and one more time to get the computation. I can get all that in one go/read with shorter text - i.e. short variable names and simple math.
Maybe I have some sort of dyslexia or something, I tend to not read big wall of text very accurately. Not just in code but also in plain English... Hence for me shorter variable name increasing my accuracy / understanding...
modified 7-Sep-21 1:48am.
|
|
|
|
|
Another angle: I do use single-letter Field names when:
1) they are used only in the scope of a Method/Function
and
2) they are, imho, easily recognized, in context, as representing logical attributes.
So, in a Method that takes a Rectangle as a parameter: I might, as the need arises, use 'w for 'Width, 'h for 'Height, etc. I only use 'i, 'j, 'k in for loops.
But, if an employer wanted longer names, no problem; the 'name issue is not a "religious" issue for me, but, I value consistency.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
yea, exactly my case...
but from the strong reaction here, I think there some brain type at work...
|
|
|
|
|
Super Lloyd wrote: so we disagree to disagree then?
You agree to disagree. If you disagree to disagree, then you agree.
|
|
|
|
|
When I came up with that sentence, I suddenly get this meaning...
Disagree to disagree is when you keep arguing with the hope I'll eventually agree...
Agree to disagree is when we both realize we ain't gonna agree...
|
|
|
|
|
Super Lloyd wrote: so we disagree to disagree then?
No. If I was the boss and an employee used Calculate as a function name I'd shitcan him or her, unless it was obviously a joke and they fixed it as soon as the laugh was had. I would not let a codebase I am responsible for be polluted by such meaningless names that all coders from there on out are going to have to spend precious time figuring out the intent of even something this simple. Among the oldest of business mantras is "Time is Money". And coding like this wastes everyone else's time. Making a lone coder happy, even if they are good, isn't worth it in cases like this.
|
|
|
|
|
We have a rule, if an acronym is well known, then we use it (eg url rather than universal resource locator), otherwise we spell out the full words.
A few years ago we where working on a system which had a limitation on some names, but we needed those names to be descriptive of the keys. We ended up with a jumble of 3 letter acronyms everywhere.
Sure enough, the parts we touched frequently where easy enough to deal with, but gee looking at some of the sections which remained fairly static was a nightmare to determine what was going on and what held what data.
|
|
|
|
|
you missed the part where I was talking about a variable.. inside a method...
|
|
|
|
|
I've also seen enough
var x = 1;
var y = 2;
var z = 3;
type code in methods to know that single letter / acronym variable names can be bad, especially that method has grown a little too big.
Whilst variable names should never be war and piece, they should be somewhat descriptive enough so that as a developer you know what values you're likely to see in there, and how they should be used.
That said, I'll happily use for (var i = 0; i < 10; i++) {} without thinking twice, so you know I'm not 100% dedicated to the no small variable names cause.
|
|
|
|
|
In an IT class I had to help someone who was a competent coder, but had a similar problem (he was dyslexic). The course specified that you should use descriptive variable names (fortunately not hungarian though). We reached a compromise: he could use short variable names wherever possible (eg inside small functional units of code - as per your example) but had to add a comment at the start of the code that explained what the variables represented. This had to be only in code that could fit on the screen so it could be read in one hit.
Ignoring - for now - the fact that no developer I've ever met (including me!) is good at keeping comments in step with the code, nevertheless this seemed a workable compromise: He could write code he could follow and there was at least a reasonable chance that the comments would give a good hint as to what was going on.
|
|
|
|
|
Hi,
In my experience, in-person meetings that were code-reviews were often a waste of time, particularly where they were "ceremonial" in nature.
However, some code reviews, where a focused-agenda meeting was called after written and verbal discussions had identified important issues ... were useful. Those were ... rare 
I use very-long names because: I'm a speed typist; because I am, these days, writing code designed to (hopefully) educate; because I like the idea that code is more "self-documenting" that way; because, in the future, I think I can "re-hydrate" that code in my head faster.
But, I'm under no peer, or deadline, pressure.
If I were a team member, I'd probably just "go with the flow," until I had enough cred to rock the boat.
I might use short-names, then longify them with an editor before submitting them ... if I could get away with that.
cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Reflecting a bit upon myself....
Long expression take more time to parse. The number of characters matter here... it's strenuous to parse long wall of text.. I might have some sort of dyslexia or something. Affect me reading novel too... I sometimes have to read paragraphs again because I only superficially read each word....
|
|
|
|
|
Super Lloyd wrote: Long expression take more time to parse.
I think time-to-parse varies a lot depending on multiple individual factors, like education, mother-tongue, certain cognitive skills.
imho, pragmatic issues can affect naming schemes; I often use Simonyi-Hungarian style names for public properties in UserControls because I want them to show up in the PropertyBrowser in a group.
For me, longer is not a problem However, I keep in mind that:Quote: Edward Sapir wrote, "When it comes to linguistic form, Plato walks with the Macedonian swineherd, Confucius with the head-hunting savage of Assam.
Consider the Bantu Kivunjo people's language, where:Quote: ... The verb "Näïkìmlyìïà," meaning "He is eating it for her," is composed of eight parts:
• N-: A marker indicating that the word is the "focus" of that point in the conversation.
• -ä-: A subject agreement marker. It identifies the eater as falling into Class 1 of the sixteen gender classes, "human singular." (Remember that to a linguist "gender" means kind, not sex.) Other genders embrace nouns that pertain to several humans, thin or extended objects, objects that come in pairs or clusters, the pairs or clusters themselves, instruments, animals, body parts, diminutives (small or cute versions of things), abstract qualities, precise locations, and general locales.
• -ï-: Present tense. Other tenses in Bantu can refer to today, earlier today, yesterday, no earlier than yesterday, yesterday or earlier, in the remote past, habitually, ongoing, consecutively, hypothetically, in the future, at an indeter-minate time, not yet, and sometimes.
• -kì-: An object agreement marker, in this case indicating that the thing eaten falls into gender Class 7.
• -m-: A benefactive marker, indicating for whose benefit the action is taking place, in this case a member of gender Class 1.
• -lyì-: The verb, "to eat."
• -ï-: An "applicative" marker, indicating that the verb's cast of players has been augmented by one additional role, in this case the benefactive. (As an analogy, imagine that in English we had to add a suffix to the verb bake when it is used in 1 baked her a cake as opposed to the usual I baked a cake.)
• -à : A final vowel, which can indicate indicative versus subjunctive mood.
If you multiply out the number of possible combinations of the seven prefixes and suffixes, the product is about half a million, and that is the number of possible forms per verb in the language. In effect, Kivunjo and languages like it are building an entire sentence inside a single complex word, the verb.
But I have been a bit unfair to English. English is genuinely crude in its "inflectional" morphology, where one modifies a word to fit the sentence, like marking a noun for the plural with -s or a verb for past tense with -ed. But English holds its own in "derivational" morphology, where one creates a new word out of an old one. For example, the suffix -able, as in learnable, teachable, and huggable...
Steven Pinker, "The Language Instinct."
Wonder if the inventors of APL were inspired by Kivunjo.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I have to agree with David O'Neal - short names are a bad idea.
There isn't just the "Understandability" factor, though that is very significant - especially when you look at the code for the first time, or after a long break from it. More significantly one character names are more prone to error, because it's very easy to hit the wrong key and get a valid variable name. While Intellisense can make that happen with more descriptive names as well, it's a lot more obvious that it's wrong.
To use your example:
Quote: it'e E=mc^2, not Energy = Mass * SpeedOfLight^2, to vindicate me...
E=nc^2 Looks vaguely right and it's easy to miss the mistake when skimming, but the longer form:
Energy = numberOfCatsInTheBox * SpeedOfLight^2 Is immediately wrong.
And ... if you are anything like me you read what you meant to write, rather than what you did type.
So short names make life harder for you, me, and everyone else who has to work with the code - so yes, code reviews should pick them up!
I'm not saying that all short names are bad, it's pointless to use a long name here:
for (int i = 0; i < rooms.Count; i++)
{
rooms[i] = new Room();
}But in general, they are a PITA!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote:
Energy = numberOfCatsInTheBox * SpeedOfLight^2 Is immediately wrong.
Especially since ^ is the Xor operator, not the "to the power of" operator. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
