|
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!
|
|
|
|
|
Oh, I thought for a short while it was the Schrödinger operator.
|
|
|
|
|
Some say the Schrodinger operator is kind of half-assed; I agree with them half the time 
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
How many times did I accidentally use the wrong shortly named variable (not sure mattered but anyway)?
Once or twice last year.
How many times I had to refactor long name into short name to improve my understanding?
Every single time.
There you have it.
Refactoring variable name to short version is the first thing I do when refactoring.
I will grant you that I might have some intellectual disability not shared by my peers (because, obviously, they have no problem with long names whereas, and I am not making this up, it's ultra confusing for me) and I have to suck it up... But that's how it work for me. And on that will disagree to disagree.
modified 7-Sep-21 3:46am.
|
|
|
|
|
Quote: How many times did I accidentally use the wrong shortly named variable that you are aware of (not sure mattered but anyway)?
That's the point: if you notice, it didn't matter. But if you don't ... it might matter a lot.
Getting rid of potential errors before they can be noticed at run time is why C# is a strongly typed language, why experienced developers normally prefer compiled languages to interpreted, and why teams insist on descriptive names ... 
"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!
|
|
|
|
|
you are become more and more bad faith.. or perhaps, conversely, your brain really do have problem with 1 letter variable that I dont.
The only time I mistake them is because I used the wrong index because I just couldn't quite remember if it was index1 (i.e. i) or index2 (i.e. j) I should use....
I never mistake w for x and I doubt you did either....
further there is one single variable in this whole block, so I am not sure how you could use it wrong accidentally...
|
|
|
|
|
And one more thing:
Super Lloyd wrote: How many times I had to refactor long name into short name to improve my understanding?
Every single time.
If you do that on team code, you are going to upset - rightly - a heck of a lot of people who have invested effort in getting the names "right" and the code self documenting.
It's a bit like pulling a whole branch, refactoring it to your prefered indentation style and pushing it back otherwise unchanged ... you are going to make enemies very quickly.
I'd suggest that you learn to live with descriptive names or the company may decide you are more trouble than you are worth ... Are you on a probationary period with EA? Most new appointments are!
"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!
|
|
|
|
|
for (int room = 0, roomCount = rooms.Count; room < roomCount; room++)
{
rooms[room] = new Room();
}
room can be replaced by pos (or anything more meaningful); anyway: anything not like this as a code will not go live for me...
Besides this point, when I had to manage core reviews, I dit it with the whole team so anybody could have seen and emphasis on different things and not only what I wanted to pinpoint.
One point missing, is that code reviews in 2021 aren't the same as those done in the 1990: now we have tools like R# Shart (no publicity intended) which are removing a lot of "discrepancies" (bugs), automating test tools, and so on. So now, code reviews are more about code's readability and maintenance.
Because of these (hey folks, dont forget you're using Intellisense which types most of the code for you!), so definitively no excuse to have readable code.
modified 8-Sep-21 13:12pm.
|
|
|
|
|
I would reject your pull request as well, if you had: a = b + c That is is just super lazy programming IMHO, and makes it very difficult for the next developer to understand.
I expect all code that comes across my desk to be as self-documenting as possible, including my own.
This crap: a = b + c is not self-documenting.
|
|
|
|
|
I am glad we disagree to disagree
|
|
|
|
|
I would also like to warn you that it may not be a good idea to publicly complain about your work related issues here, seeing that we all know you work for EA now and EA employees may frequent this site and forum.
Just a thought...Job security and all. I'm sure you understand. 
|
|
|
|
|
sshh dont advertise it now!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
