- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
In part this is personal preference, in part it's because I'm a C++ guy who is very much in favor of the commandment "an identifier is all-caps iff it is a preprocessor macro", which means that a name like LUB, SCUBA, or HTTP can't be used for a non-macro.
Admin
My preference (for HttpRequest to HTTPRequest) has a couple other reasons too:
What do you do if the acronym is first but should be lower camel case? httpRequest or hTTPRequest? The second looks incredibly stupid to me, but IMO the first is inconsistent: is "http" a word (in which case HttpRequest) or not (in which case hTTPRequest)?
What if you want to acronyms adjacent to one another? Now you need to do something like ABCD_EFGH. But why is that named that, and FooBar doesn't have an underscore? Inconsistent.
Camel casing relies on the switches between upper and lowercase to make it easy to spot the different "words" in an identifier. Words here is what your brain will chunk together. Unless you literally think of "HTTP" as three or four separate things instead of one thing (e.g. it uses four slots of your 7 +/-2 short-term memory slots), IMO it's better to make the chunk easier to pick out, and treating the whole thing as a word makes that easier.
I'm assuming camel casing here... things are a lot less important if you do underscore_identifiers. HTTP_request reads fine I think. But you still run afoul of my macro commandment in C and C++, so for those languages I still would prefer lowercasing things.
Admin
I think the "LU" stands for "LookUp"
Admin
It is not a good idea to have a name that describes what the table/stored procedure/method contains, or returns. Details should be private to the implementation and not exposed, because, it leads to problems when changes are necessary to the implemenation. Refactoring code is (relatively) easy, but updating all references to a table/stored proc can be very difficult.
Additionally, having that additional information is generally useless (why does a user of a table care what the foreign keys are? Table insert/update should be through stored procedures anyway, because you cannot insert/update into multiple tables in a single statement,... don't get me started on transactions).
Admin
The original data model of my current project at work started the same way (although recently, the convention is being phased out), which gave us such awesome table names as:
relFloodzoneDocumentCategoryApplicationTypes
Then, when the table names started getting too long, abbreviations where used, which left us with gems such as:
relInsSpReqPermCodeRelFldZonePermClsCodes
Yeah... "Descriptive"...
Admin
There's always "laser" but you still have to pronounce the quotation marks.
Admin
FTFY
Admin
I sure hope Discourse never does, because (queue CodingHorror tone) "ads derail conversation".
sarcasm:off
Admin
Admin
Now if the EmployeeTable contains a foreign key to the DepartmentTable for each employee, then (obviously) we must call it the DepartmentEmployeeTable. But if the department table holds a foreign key to the employee who manages it, then the department table must be called DepartmentEmployeeDepartmentTable. But then we need to change the name of the employee table, and then the department table... recursively! >;->
Admin
http://thedailywtf.com/Articles/Who-is-Kyle-Soze.aspx
Admin
I don't think it's long names per se, it's when you have a bunch of long names that are all very similar except for something hidden in the middle. For example:
GetAutomationExportAutomationExportFieldLUByAutomationExportID
and
GetAutomationExportAutomationImportFieldLUByAutomationExportID
If with auto-completion in your IDE, keeping those two straight is tiring.
Admin
"In our database", said B-TreeBeard, "the name of a table is the story of the table."
Admin
The name of a table shouldn't describe what the table contains? What should they be called then? Table1, Table2?
Admin
I'm writing import/export integrations at the moment and even with three words in dB table names/variable names/file names I have confused import and export.
Admin
Admin
This. Exactly this.
You should optimize the code you write for reading comprehension, because you might someday desperately need to understand WTF you were thinking.
Admin
Admin
The statement was referring to the practice of adding extra information to a name that is not particularly needed - not reducing the table name to a meaningless id.
i.e. an employee table that contains a foreign key to an address table should just be an Employee, not EmployeeAddress, as the foreign key is not necessary to describe the table. In other words, just because there is an AddressID in the table doesn't mean the table contains address information. Linking tables (i.e. many-many) that ONLY contain foreign keys would be candidates for that naming convention though.
If I have a method that sorts items in a class, I can use the name Sort, as I do not want to expose the implementation (maybe it's a QuickSort, or it might be a BubbleSort), because I might want to later change the implementation without changing the interface.
Admin
Sorry about the double post, I don't know how to edit/delete the prior one...
The statement was referring to the practice of adding extra information to a name that is not particularly needed - not reducing the table name to a meaningless id.
i.e. an employee table that contains a foreign key to an address table should just be an Employee, not EmployeeAddress, as the foreign key is not necessary to describe the table. In other words, just because there is an AddressID in the table doesn't mean the table contains address information. Linking tables (i.e. many-many) that ONLY contain foreign keys would be candidates for that naming convention though.
If I have a method that sorts items in a class, I can use the name Sort, as I do not want to expose the implementation (maybe it's a QuickSort, or it might be a BubbleSort), because I might want to later change the implementation without changing the interface.
Admin
Oh wait, that's only true sometimes. It's easy to make two, but hard to make zero.
Admin
Isn't that essentially what a database is? Not sure about other databases, but a SqlServer database is just a .mdb (unless you do something special to have it across multiple files).
No, the sarcasm is not lost on me ;)
Admin
A(B,C) = probably not good. RSAEncrypt(EncString, RSAParamList) = probably not bad. EncodeAccordingToAlgorithmCreatedByRivestShamirAddlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat(StringWhichNeedsToBeEncodedPreferablyUsingTheAlgorithmInventedByRivestShamirAdlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat, LongListOfParametersWithExcessiveNamesPreferablyListedIndividuallyButEachWithALongName) = perhaps a little ott....
Admin
Don't mix abbreviations and non Abbreviations. If you use enc once, use it all the time, if you use encrypt once, use it every time.....
Nothing worse than digging through stuff that randomly alternate between: CODED_NAME CODE_NAME CODE_NME CDE_NME CDE_NAME CODE_NME CODED_NME (even more fun when case counts)
Admin
Admin
Sounds like someone has never actually denormalized anything. In relational databases you can use views and transactions should cope with race conditions. In many NoSQL databases the data is denormalized by the nature of it's format or its index.
It has nothing to do with simplifying the database diagram and everything to do with improving performance by more closely representing those relationships. Done wrong, it can be bad, no doubt. However, that's why you shouldn't let people who only understand relational databases , and fear denormalization, do it.
Admin
Simple solution - code in KNF (Kernel Normal Form) where your functions each fit in to much less than a single screen, and your code will be readable however you name your variables.
Admin
Mozilla Gecko has services that deal with international domain names and the domain name system, amongst others. Naturally code doesn't invoke the service directly, instead calling via interfaces. The four names in question? nsIIDNService, nsIDNSService, nsIDNService, nsDNSService.
Admin
I don't really think it's a problem with long name, if anything it could be just missing seperators.
Take the name provided for example: GetAutomationExportAutomationExportFieldLUByAutomationExportID()
In my company I would have been required to name it as: sp_ModuleName_Get_AutomationExport_AutomationExportFieldLU_By_AutomationExportID()
Now it's pretty clear what it does and which module it's been made for, isn't it?
Admin
There's "unreadably short", "concise", "verbose", and ENTERPRISE QUALITY.
Admin
CountryTable AddressTable AddressCountryTable -- Foreign keys to AddressTable and CountryTable
The following example could be considered perfectly valid if it were not dealing w/ address and country. Information as to how the relationship exists between these tables is left out and is generally necessary. Is this a 1:M relationship, a 1:1 relationship, M:N, "is a x", "has a x"?
Since the initial example could have been changed to protect the guilty parties, it's quite possible that an M:N relationship existed, at which point, the concatenation of the two names is sensible.
In regards to this specific example, however, it really doesn't make sense. An address should ever only exist in one country, so the choice in concatenating the names is a poor one.
I always argue that IF there is a real-world naming convention for an M:N relationship between two tables, use that instead of concatenating the names together. You really want to model that which exists w/ naming conventions that make it apparent how it relates to real world entities. Good requirements will use similar terms in most cases. If an M:N relationship between data exists but isn't defined by a real-world entity with its own name, then certainly concatenating the names is fine.
Admin
Admin
How can the result of a query be private?
I tend to name tables after a thing, if one table has a single relationship into another table then it's named after the thing, if there are more than one then you specify something about what type of thing it is.
So you'd have an Address table and a Customer table. If a Customer only has one Address then call the relationship Address, if you have a delivery and invoice address then name them DeliveryAddress and InvoiceAddress.
You could argue that if you start with one and then add another one then you'll need to rewrite some code, but there is no alternative. You change your data structure and you're going to be changing code (stored procedures are also code). Forcing all queries to be performed using stored procedures doesn't solve the problem and just causes more.
I got bored reading the article to figure out if there was a WTF
Admin
ok, i just have to copy this classic joke here:
In the Beginning was The Plan And then came the Assumptions And the Assumptions were without form And the Plan was completely without substance And the darkness was upon the face of the Workers And the Workers spoke amongst themselves, saying "It is a crock of shit, and it stinketh." And the Workers went unto their Supervisors and sayeth, "It is a pail of dung and none may abide the odor thereof." And the Supervisors went unto their Managers and sayeth unto them, "It is a container of excrement and it is very strong, such that none may abide by it." And the Managers went unto their Directors and sayeth, "It is a vessel of fertilizer, and none may abide its strength." And the Directors spoke among themselves, saying one to another, "It contains that which aids plant growth, and it is very strong." And the Directors went unto the Vice Presidents and sayeth unto them, "It promotes growth and is very powerful." And the Vice Presidents went unto the President and sayeth unto him, "This new Plan will actively promote the growth and efficiency of this Company, and in these Areas in particular." And the President looked upon The Plan, And saw that it was good, and The Plan became Policy. And this is how Shit Happens.