CppCon 2019: Kate Gregory “Naming is Hard: Let's Do Better”
Vložit
- čas přidán 15. 05. 2024
- CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2019
-
C++ developers are famously bad at naming: our idioms, guidelines, and lore are rich in examples of terrible names. For example, consider RAII, which stands for scope bound resource management, or west const which perhaps should be const west, or all the samples that feature an object called x which is an instance of a class called X, and so on.
The good news is that naming well is a learned skill, and you can learn it, and start to name better right away. In this talk, I'll tell you why names matter, what benefits a good name can bring, and how to be better at naming. I'll discuss some categories of names and some common decisions within those categories. I'm not going to give you a set of rules to follow: this is about thinking and considering the meaning of the things you are naming. I will give you some questions to ask yourself and some structure that I use to help me to help those who read what I write.
I'll also address renaming things in existing (legacy) code, why and when to do it, and why getting it right the first time may not even be a realistic goal. You should be a lot more confident naming things after we spend this time together.
-
Kate Gregory
Gregory Consulting
Partner
Kate Gregory has been using C++ since before Microsoft had a C++ compiler. She writes, mentors, codes, and leads projects, in both C++ and .NET, especially for Windows. Kate is a Microsoft Regional Director, a Visual C++ MVP, has written over a dozen books, and speaks at conferences and user groups around the world. Kate develops courses on C++, Visual Studio, and Windows programming for Pluralsight.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
"Remember, a question is when you want more information from me."
Reason #153 demonstrating why Kate Gregory is the hero we need.
Pffft. You can always make a statement and then say, "Why do you think otherwise?"
@@prezadent1 : You can do that, but there is a clear and visible difference between wanting more information, and posturing as wanting more information when one doesn't.
54:06 This demonstrates Kate's point that "Naming is Hard" as "Cars" is a name that perhaps only some in the world associate with a Train, the rest of us would think of that as a Railway Carriage!
I don't know why but the presentations from Kate just make me want to go back and rewrite all my code to be more "pleasant" and "readable" ...
Kate Gregory, back at it again with another slam dunk talk
Kate, Bjarne, Chandler are the ones I look forward to every year.
Herb too.
Herb Sutter, Jason Turner
such an amazing lady, always has some real-life lesson
I've been looking forward to seeing this all week
Kate's talks are always amazing :D
Could listen to her all day long. So soothing.
I remember first time doing a project with another person (my friend)
And we looked through 2d array many times in different parts of code
And we kept confusing x and y coordinates
When we changed to "row" and "column", everything became a lot easier
note that the first index of a 2d array doesn't have to be the row index.
As a non native speaker, rows and columns are ultimately more confusing than just using x and y.
Even better off, you can get used to "i,j" notation, which comes from math, and is even intuitive in way of for loops (i for outer and j for inner one)
I second that rows and columns always confuses me a lot. I'm a native german speaker.
Native english speaker here too, not sure why but row and column always trip me up. (i,j) are worse but maybe that's just because I failed linear algebra. Though to be fair x and y also get confusing when you're working in screen space with y=0 being at the top of the screen instead of the bottom so maybe nothing is perfect. ¯\_(ツ)_/¯
@@Antagon666but which dimension is which? I always need to check how matrix elements are ordered when I do things.
This talk is so good. This is my 3rd time watching it and it still helps
I can't even empathize for "the future me in 1h" and I often blame it on "the past me 1h ago"
These conferences are great. I hope one day I'll be able to come!
partial_sort is not optimal naming if you do not know that function exists. If it was sort_partial then auto fill can suggest it.
25:10 IMO "Inventory check" is a noun. "Check inventory" is a verb. A funtion named "InventoryCheck" will perform an inventory check, while a function named "CheckInventory" will check inventory. Same with "EmployeeUpdate". However, "Determine" and "Charge" are not nouns you can so easily perform, so they can't be flipped that way.
Kate Gregory delivered another great talk.
Partial_sort_copy has nothing on transform_inclusive_scan. At least _copy is a pretty internally consistent suffix in the algorithm header.
I strongly disagree that template parameters can be called T. They should usually be called according to the concept they represent, like "NumberT", "DifferenceElementT", "AllocatorT" etc. Only in some very obvious cases, or when you have some internal template inside a very small scope, you can call the parameter T. This is analogous to the guidelines for variable names.
Can I Call them Number, DifferenceElement, Allocator intead?
Concepts should be preferred but when it doesn't matter @data_structures I use T.
Maybe add traits, Trivial, Floating, Int etc. for different types in those
Encoding template parameter with concept name is like encoding type into parameter name.
I use allocator_t for template parameters. I know it's not particularly standard, but I like the _t for type aliases.
All clear to me.
I think we should create a website just for that. A coder name generator with a database that grows, with English dictionary and translation contributors.
You know, they discovered this fleshy faculty of the human body that’s been in development for awhile. It’s supposed to be pretty darn good at pattern recognition, making short & long term relations, and encoding all of this with minimal net enthalpy, given other biological constraints. It’s had a quite a few “commits”, some major contributors being God and Father Time. I can’t remember the name of it, but poke around and you might rediscover it’s name!
I slightly disagree with the top_n name for partial_sort_copy because top_n does not say if we want the top n elements sorted neither if we want the results inplace
"User-facing variable should have the same name as they are presented to the user". I was pondering a lot on this exact thing, because I do notice that frequently you have to present a variable to the user with a slightly incorrect, but greatly simplified name, for the sake of accessibility and ease of use. I want to agree with her, but I'm not sure it's actually worth naming a variable a little bit incorrectly to make it easier to read.
What do you think of using nouns to name pure functions? This is a convention in some functional programming. Do you think it makes sense in C++?
What's an example of that?
@@SolomonUcko maybe something like "arraySum(array)" that returns the sum an array of numbers. Like a property that needs to be calculated.
43:32 I need that mug!
22:00 - Sometimes source goes with target. Compilers read source files outputs target files.
"Functions should be named as verbs" sounds trivial, but I'm sure the STL committee is shocked to hear this.
A couple comments. To get better at naming, write. Or at least, read fiction. Also, learn about the wider world outside of software; science, math, history, sports, etc.
isShippable() is fine, in that it makes the intention clearer than most alternatives. empty() is terrible indeed.
Naming conventions are very important though. Why do all the functions in the slides start with Capital? Why use a different convention than what the STL uses for example, just to make reading harder? You can't have consistency if code you use (the standard lib) has a different convention. That's not against the presenter by the way.
Why use T in cases where it's clear that T has one specific property, other than "it is the data type" in a template? It gets worse when there are 2 or more type parameters, who of course have different uses, named T, E...
I will start with the e_Lephant_m_. If vector is a class, doesn't matter if it is a template, it should start with a Capital. Why do you propose that i should start naming anything in my code with a Capital when a class in the STL starts with a small letter? Is there a technical reason to have different guidelines for other code than what we use in STL, like "STL has to run everywhere, but for your code i don't care"?. Well that ship has sailed. But if this is the case, the guide should be to also name every type with a small letter as well, which is what we also do with variable names etc. An opportunity to help people write more readable code has been missed here.
There is a need for rules/guidelines, that should apply to the STL first (at least the new stuff, if it's different than what we have), and then gradually be adopted by others.
As for the meaning of functions as portrayed by their names: I don't think you always need to start with a verb but it's a good rule. However starting a function name with the domain it refers to is more appropriate in most cases. So inventoryCheck() is fine, if it's in a class or module/namespace that deals with more domains than the inventory. If not, just use the verb. Either of the approaches is fine, as long as the intent is clear.
WellDone KATE Great_Job I_Think_I_Get_It... Empty()
> top_n
actually returns bottom n
> Name()
inb4: every function should be a verb
I agree with most of the speaker's logic, but I don't think she genuinely follows it when making actual naming decisions.
Source and target are a perfectly normal pair. Destination is an existing output, target is a desired output. Transforms into something source container->dest container, transforms to something source format->target format, a destination format would the format of the destination not a format that _is_ the destination, but target format is.
Even if one takes your distinction between destination and target at face value, it still doesn't support source/target as a pair. Source/destination is the pair, and target is a property of the destination.
Empathy? I don't know what that is. I'll go back to my Applicationmanager_Handler class.
The world'is worst name is the Unix "cat" command.
perfect example to contradict the very presentation( first part - "dont call it expiry date, call inactive date", next - "don't invent business words") "expiry date" is a proper financial term ( as well a legal , if I am not mistaken) , "inactive date" is not . So , the moral of the story - don't blindly listen for an unsolicited, uninformed advise)
You’ve misunderstood. When she says “business” she means business logic. This is not the same as being “business term” or formal or correct term. Business logic in programming is something that expresses the real world rules of how something is operated/applied/calculated etc. So when she is talking about the implicit business logic of expiry date vs inactive date, she means the implicit encoding of how the value is to be used in the program, by the name of the variable.
Real programmers name everything with just consonants. Vowels are for the weak.
Real programmers use register numbers and memory addresses. Names are for the weak.
This is where OOP gets you: More hours spent on naming 'things' that do no map to real world objects and less on actually writing good code.
I don't understand those jabs at ECMAScript. The APIs provided have very sensible names even considering the fierce competition of nonstandard implementations in the early 2000s.
Did she mean to say the DOM API, which is completely separate from it?
I don't understand this blind hate stemming from ignorance.
No, the actual name ECMAScript. Legend has it nobody could agree on a name, so they chose a placeholder they all hated and would be highly motivated to replace at the end of the process, then couldn't agree still so it went out with a name everyone hated. No more than that. Nothing about APIs or DOMs or whatnot. And no blind hate either.
Appreciate the clarification and apologies if I made too many assumptions there.
Indeed the naming in that regard can be a bit confusing, especially with the versioning scheme change since ES6 (or ES2015) and the standards name not aligning with the name everyone knows the language as.
But it is also not easy to ignore the fact that far too many people make negative remarks towards JS with the reasoning (if they give any) being "oh because it's JS"
@@gregcons No, the problem was there was two competing languages JScript and JavaScript, ECMAScript was the standardization of the two and made them one. So it was originally separate from JavaScript by being JScript compatible, but we still just mostly call in JavaScript though that is technically wrong.