Related
I am wondering if there are any agreed upon naming conventions for intents, events and contexts in Dialogflow.
If there are none, then I would appreciate if you shared your own naming conventions!
I find that it's a bit of a contradiction to say 'it doesn’t really matter as long as it‘s easy to understand for others'. If there were naming conventions, it would be much easier for someone to understand a new Dialogflow bot.
Here's my take:
Intents
I use dots to group intents and imply a hierarchy. The first part of the intent name is ideally just one word that clearly indicates the main subject of the intent. For example
name would be an intent that receives a user's name as an input. name.confirm would be the follow-up intent that receives confirmation of the name. name.confirm.yes would be the intent where the user has given confirmation.
This is in the context of a bot which is gathering contact data so the input function is implied. In a more mixed-type chatbot, you could add the type of intent as a first word to categorize your intents better. E.g. input.name.confirm.yes or FAQ.shipping.overseas or smalltalk.agent.location ('Where are you?').
I use the same approach for fallback intents: fallback.name would be the fallback intent that is triggered when the bot is waiting for the user to input their name but doesn't understand the answer.
Contexts
For contexts I use snake case. For example awaiting_email would be the context that is set when the bot is waiting for the user to input their email address. After I have the email address I would set a context email to carry forward the information so that other intents can use it as a context. Or if I'm collecting several pieces of data about the user, I will set the context user and other intents can access certain parameters e.g. via user.email.
I made a video about the topic as well: https://youtu.be/kgKuS2RJcy4
It's obvious that everyone is coming from a slightly different angle because their area of application is different. I'm sure we'll get to a common standard eventually!
I am going to answer this from perspective of a service based company's project.
In my project, we have used similar naming convention for intents as in-built small-talk intents, because its easy to understand and categorize. like FAQ.Comapny.your_question, Buy.Drinks.coffee etc.
(for some unknown reasons we capitalize the first letter of main categories of intents, in small-talk all letters are lower case as it should be).
For the events we have used similar notation for universal constants, like INVOKE_EVENT.
For parameters and contexts, we used snake_case i.e coffee_cost.
Basically, it doesn't really matter as long as it's easy to understand and replicate. But you should always have a basic structure which you and your whole team follows throughout the project.
There aren't any, unfortunately, and the system is flexible enough that it doesn't matter too much. Pick names that make sense (duh).
Although most of the examples use it, I avoid using a space in the name. I treat them more like function names, so having a space in it breaks my aesthetics.
I tend to group Intents based around what part of the conversation they're working on, which is managed through the use of contexts that are set, and separate the part and subpart designations by dots, so it vaguely looks like package designations. I'll have Intents named something like
calculate.fallback
calculate.number
calculate.operation
fallback
welcome
Where the "calculate" ones all have an Input Context of "calculate".
Most of all, remember that Intents (and thus their names) represent what the user says and not what your code does with that. This is the big way that it differs from a function name.
Honestly, it really doesnt matter! As long as its easy to replicate in code and clear to see/understand for anyone else that might be working on your agent, then anything is fine. Generally though using typical coding notation such as CamelCase is probably not a bad idea.
What is a scenario that exemplifies a good reason to use prefixes, such as fn_GetName, on function names in SQL Server? It would seem that it would be unnecessary since usually the context of its usage would make it clear that it's a function. I have not used any other language that has ever needed prefixes on functions, and I can't think of a good scenario that would show why SQL is any different.
My only thinking is that perhaps in older IDE's it was useful for grouping functions together when the database objects were all listed together, but modern IDE's already make it clear what is a function.
You are correct about older IDEs
As a DBA, trying to fix permissions using SQL Server Enterprise Manager (SQL Server 2000 and 7.0), it was complete bugger trying to view permissions. If you had ufn or usp or vw it became easier to group things together because of how the GUI presented the data.
Saying that, if you have SELECT * FROM Thing, what is Thing? A view or a table? It may work for you as a developer but it will crash when deployed because you don't grant permissions on the table itself: only views or procs. Surely a vwThing will keep your blood pressure down...?
If you use schemas, it becomes irrelevant. You can "namespace" your objects. For example, tables in "Data" and other objects per client in other schemas eg WebGUI
Edit:
Function. You have table valued and scalar functions. If you stick with the code "VerbNoun" concept, how do you know which is which without some other clue. (of course, this can't happen because object names are unique)
SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetName()
If you use a plural to signify a table valued function, this is arguably worse
SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetNames()
Whereas this is less ambiguous, albeit offensive to some folk ;-)
SELECT dbo.sfnGetName() FROM MyTable
SELECT * FROM dbo.tfnGetName()
With schemas. And no name ambiguity.
SELECT ScalarFN.GetName() FROM MyTable
SELECT * FROM TableFN.GetName()
Your "any other language" comment doesn't apply. SQL isn't structured like c#, Java, f#, Ada (OK, PL/SQL might be), VBA, whatever: there is no object or namespace hierarchy. No Object.DoStuff method stuff.
A prefix may be just the thing to keep you sane...
There's no need to prefix function names with fn_ any more than there's a need to prefix table names with t_ (a convention I have seen). This sort of systematic prefix tends to be used by people who are not yet comfortable with the language and who need the convention as an extra help to understanding the code.
Like all naming conventions, it hardly matters what the convention actually is. What really matter is to be consistent. So even if the convention is wrong, it is still important to stick to it for consistency. Yes, it may be argued that if the naming convention is wrong then it should be changed, but the effort implies a lot: rename all objects, change source code, all maintenance procedures, get the dev team committed to follow the new convention, have all the support and ops personnel follow the new rules etc etc. On a large org, the effort to change a well established naming convention is just simply overwhelming.
I don't know what your situation is, but you should consider carefully before proposing a naming convention change just for sake of 'pretty'. No matter how bad the existing naming convention in your org is, is far better to stick to it and keep the naming consistency than to ignore it and start your own.
Of course, more often than not, the naming convention is not only bad, is also not followed and names are inconsistent. In that case, sucks to be you...
What is a scenario that exemplifies a
good reason to use prefixes
THere is none. People do all kind of stuff because they always did so, and quite a number of bad habits are explained with ancient knowledge that is wrong for many years.
I'm not a fan of prefixes, but perhaps one advantage could be that these fn_ prefixes might make it easier to identify that a particular function is user-defined, rather than in-built.
We had many painful meetings at our company about this. IMO, we don't need prefixes on any object names. However, you could make an argument for putting them on views, if the name of the view might conflict with the underlying table name.
In any case, there is no SQL requirement that prefixes be used, and frankly, IMO, they have no real value.
As others have noticed, any scenario you define can easily be challenged, so there's no rule defining it as necessary; however, there's equally no rule saying it's unnecessary, either. Like all naming conventions, it's more important to have consistent usage rather than justification.
One (and the only) advantage I can think of is that it a consequently applied prefixing scheme could make using intellisense / autocomplete easier since related functionality is automagically grouped together.
Since I recently stumbled over this question, I'd like to add the following point in favour of prefixes: Imagine, you have some object id from some system table and you want to determine whether it's a function, proc, view etc. You could of course run a test for each type, it's much easier though to extract the prefix from the object name and then act upon that. This gets even easier when you use an underscore to separate the prefix from the name, e.g. usp_Foo instead of uspFoo. IMHO it's not just about stupid IDEs.
PostgreSQL has allowed me to name a column "campaign_$". I like the name because it's short and to the point, and other potential names like "campaign_receipts" seem longer and less clear.
BUT, I wonder if I'll eventually regret putting a $ symbol in a column name, either in PHP or in some other distant part of the architecture. Should I just stick to letters and underscores?
Thanks!
Yes, you should. "campaign_receipts" is a better name.
You probably won't regret, but I still wouldn't recommend it.
What happens when you expand into Europe?
Also, it will look strange and confusing to new developers.
In addition to the other excellent reasons I'll also mention that "$" in my mind is not clear at all. Does that mean campaign expenses? Campaign savings? Campaign values?
There's a VERY strong convention that tables and columns are named using only letters, numbers, and (possibly) underscores, so I would consider this poor style. Beyond the i18n concerns that other posters mention, there are probably a very large number of tools that expect table and column names following this convention.
I think it is bad practice to put special characters into a column name. Just spell out the word like campaign_money or campaign_funds and then the issue of internationalization or other possible issues become a thing of the past.
It should be fine, however it may cause you more problems down the line when you want to export the data to another system, things like that.
It's good to get into the habbit of naming columns/variables etc with no special characters, as usually they are more trouble than they are worth.
I wouldn't use it.
The "$" might not be valid in future databases you use (at some point you might migrate away from PostgreSQL to something else) and it also might pose problems at the application level if you do anything that maps column names to object properties if your programming language doesn't allow method names to have "$" in them.
Just my suggestion.
Can anyone make really a good case ( :-) ) for being case sensitive?
C#: case sensitive
VB.NET: not case sensitive
C++: case sensitive
...
Worse part: XML which is used inside a language like VB.NET is case sensitive.
I was making the case that it is ridiculous and can only cause harm after we found a bug in our system due to the fact that XML had both Value and value nodes...
I am asked over and over in comments
"Perhaps you can come up with a single
argument for why case insensitive is
the right choice in such a world?"
Here is an example:
I see it analogous to the issue of: URL's should be case sensitive?
www.cnn.com <> Www.cNN.com ?
Of course they should be the same, ID theft heaven! because humans don't put that much attention to 2 strings that are the same but might have otherwise different casing. Programmers are humans. So getAge() and getage() are the same in most human's minds.
Please notice: I do not think we want the code to actually have a function defined as getAget() and then have code calling it getage(), VS (vb.net) will automatically correct getaget to getAge. So the code is clear and the programmer is aware of the correct capitalization. My point is: good IDE makes the issue non relevant, but it works better in a non case-sesnsetive language like vb.net then lets say c#.
Reference: here
Case rules depend on culture. Do you want a programming language where a variable i is sometimes considered to be the same as one called I and sometimes they're different variables? (That's not a made-up example, btw. In Turkish, I is not an upper-case i.
Honestly, it's pretty simple. Do you want the compiler to correct you when you make a typo, or do you want it to guess at what you meant? The latter leads to bugs, as you found out. VB assumes "oh, you probably meant the same thing, that's ok, we won't stop you", and XML took you literally.
Your bug didn't occur because case sensitivity is bad, it occurred because being sloppy is bad. Arbitrarily changing case may, at best, cause no problems, and at worst it will cause errors. Assume the worst, and be consistent with your case. Which, incidentally, is what case sensitive languages force you to do. Whether or not your tools are case sensitive, the programmer should be case sensitive. Being case sensitive saves you a lot of trouble as long as the world features insensitive as well as sensitive tools. If we could remake the world so that everything was case insensitive, a lot of the reasons in favor of sensitivity would go away. but we can't.
A little side note of course:
In many languages, it is common to give variables and types the same names, but with different capitalization:
Foo foo; // declare a variable foo of type Foo
Of course you could argue that "you shouldn't do that", but it's convenient, and it immediately tells the reader what type the variable has. It allows us to create a Log class, and a log object. And since the purpose of this object is to log, the name is kinda obvious.
And a final point to consider:
Case matters in real languages. A word that begins with upper-case is different from the same one but with leading lower-case. The word "worD" is not correct english. Information is encoded in the case, which makes text easier to read. It tells us when we encounter a name, for example, or when a sentence begins, which is handy. Allowing people to ignore case rules makes text harder to read. And since code should generally be written as readable as possible, why shouldn't we do the same in programming? Allow the case to encode important information. In many languages, Foo is a type, and foo is a variable. That's important information. I want to know this when I program. If I see a function called "Getage", I wonder if that's some English word I've never heard before. But when I see "GetAge", I immediately know that it should be read as the word "Get" followed by the word "Age".
By the way, here's a nice example of the fun surprises you can run into in case sensitive languages.
Slop is never a good idea in a programming language. You want things to be as specific as possible. You never want your language to guess at anything and it should allow as few ways to solve a given problem as possible.
As for a specific answer, how about readability? Doesn't stoRetroData visually differ quite a bit from storeTRodAtA? Not that anyone would do such a thing, but what's the point in allowing it?
I can't come up with any reason to allow ignoring case.
At least that's my opinion--but your mileage may vary.
Edit: I probably should have started this out with a disclaimer:
I learned to program in basic and had this same thought fleetingly about 18 years ago. Trust me, it's one of those things you'll look back on in 20 years and go "Oh, yeah, I was pretty wrong about that" (as I am right now)
History It is the way it has been done. The XML is VB.NET is case sensitive because the XML standard requires it
Internationalization Are we going to support case in all languages (French, Japanese, Hebrew, Klingon, etc.)?
Several case sensitive languages nowadays are that way because the languages they were based on were case sensitive and the transition would be easier. Personally I prefer case sensitive, but Jeff Atwood wrote a pretty good article on why case sensitivity may no longer be necessary.
Couple of reasons.
Finding things, with case-insensitive I'd have to have 'case-insensitive' flag about everywhere. With UTF-8 that should be also aware of Klingon smallcase..
More importaintly, CamelCasing, CAMelcaSing. It's not pretty, but it's used a lot and is fairly sane. Is nigh impossible with case-insensitivity.
Language parity, for example xsd.exe (shipped with VS200x) can generate you classes for xsd that you supply. What would be your "Value" named when you also have "value"? So this takes out yet another possible impedance.
Case is good in programming languages, but rather than use it in symbol names we should use it as it was originally intended- to delimit the beginning of a sentence or command or a proper name. For example:
Var test = 0;
Console.writeline(test);
Test = test + 1;
Console.writeline(test);
So beautiful,... :P
I find case-insensitivity to be just silly. You should follow the capitalization of the original declaration. I can't see any good reasons for not doing so beside being too lazy to type TheRealName instead of therealname.
In fact, I would never even consider using a case-insensitive language.
Most languages give guidelines to separate different words of a name by underscores (python, C etc.) or by camel-casing (Java). However the problem is when to consider the names as separate. The options are:
1) Do it at every instance when separate words from the English dictionary occur e.g. create_gui(), recv_msg(), createGui(), recvMsg() etc.
2) Use some intuition to decide when to do this and when not to do this e.g. recvmsg() is OK, but its better to have create_gui() .
What is this intuition?
The question looks trivial. But it presents a problem which is common and takes at least 5 seconds for each instance whenever it appears.
I always do your option 1, and as far as I can tell, all modern frameworks do.
One thing that comes to mind that just sticks names together is the standard C library. But its function names are often pretty cryptic anyway.
I'm probably biased as an Objective-C programmer, where things tend to be quite spelled out, but I'd never have a method like recvMsg. It would be receiveMessage (and the first parameter should be of type Message; if it's a string, then it should be receiveString or possibly receiveMessageString depending on context). When you spell things out this way, I think the question tends to go away. You would never say receivemessage.
The only time I abbreviate is when the abbreviation is more clear than the full version. createGUI is good because "GUI" (gooey) is the common way we say it in English. createGraphicalUserInterface is actually more confusing, so should be avoided.
So to the original question, I believe #1 is best, but coupled with an opposition to unclear abbreviations.
One of the most foolish naming choices ever made in Unix was creat(), making a nonsense word to save one keystroke. Code is written once and read many times, so it should be biased towards ease of reading rather than writing.
For me, and this is just me, I prefer to follow whatever is conventional for the language, thus camelCase for Java and C++, underscore for C and SQL.
But whatever you do, be consistent within any source file or project. The reader of your code will thank you; seeing an identifier that is inconsistent with most others makes the reader pause and ask "is something different going on with this identifier? Is there something here I should be noticing?"
Or in other words, follow the Principal of Least Surprise.
Edit: This got downmodded why??
Just follow coding style, such moments usually well described.
For example:
ClassNamesInCamelNotaionWithFirstLetterCapitalized
classMethod()
classMember
CONSTANTS_IN_UPPERCASE_WITH_UNDERSCORE
local_variables_in_lowercase_with_underscores