• Evan (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    If a "LUB" is a company-known acronym, then it is better to name it "Lub".

    If it is an abbreviation, then Mixed case. If it is an Acronym the Upper Case. Some words start out as acronyms, but are later recognized as words (SCUBA/Scuba being perhaps the most common).

    I prefer camel case even for acronyms -- e.g. HttpRequest.

    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.

  • Evan (unregistered)

    My preference (for HttpRequest to HTTPRequest) has a couple other reasons too:

    1. 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)?

    2. 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.

    3. 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.

  • vali1005 (unregistered)
    GetAutomationExportAutomationExportFieldLUByAutomationExportID

    I think the "LU" stands for "LookUp"

  • Brad Ford (unregistered)

    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).

  • TenshiNo (unregistered)

    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"...

  • (cs) in reply to Sven
    Sven:
    Radar, Modem, ... I'm sure there are more

    There's always "laser" but you still have to pronounce the quotation marks.

  • (cs) in reply to Evan
    Evan:
    My preference (for HttpRequest to HTTPRequest) has a couple other reasons too:

    1. What do you do if the initialism 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)?

    2. What if you want to initialisms 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.

    3. 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.

    FTFY

  • A Non. E. Mouse (unregistered) in reply to faoileag
    faoileag:
    Another reason could be that CS allows him to show BuildMaster ads to us; something Discourse doesn't seem to support (at least there aren't any yet).
    sarcasm:on

    I sure hope Discourse never does, because (queue CodingHorror tone) "ads derail conversation".

    sarcasm:off

  • QJo (unregistered) in reply to El Guaco
    El Guaco:
    This is just another case of the old axiom - There are only two hard things in Computer Science: cache invalidation and naming things.
    and off by one errors.
  • Jeff Grigg (unregistered)

    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! >;->

  • sol (unregistered)

    http://thedailywtf.com/Articles/Who-is-Kyle-Soze.aspx

  • Anon (unregistered) in reply to Miriam
    Miriam:
    Hey, those look just like the method names I see in Java!

    tbh, I never understood why so many people dislike long variable names.

    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.

  • Dominic (unregistered)

    "In our database", said B-TreeBeard, "the name of a table is the story of the table."

  • (cs) in reply to Brad Ford
    Brad Ford:
    It is not a good idea to have a name that describes what the table/stored procedure/method contains, or returns.

    The name of a table shouldn't describe what the table contains? What should they be called then? Table1, Table2?

  • (cs) in reply to Anon
    Anon:
    Miriam:
    Hey, those look just like the method names I see in Java!

    tbh, I never understood why so many people dislike long variable names.

    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.

    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.

  • commoveo (unregistered) in reply to nasch
    nasch:
    Brad Ford:
    It is not a good idea to have a name that describes what the table/stored procedure/method contains, or returns.

    The name of a table shouldn't describe what the table contains? What should they be called then? Table1, Table2?

    Bah! Who needs tables, just store everything in one big flat-file.

  • The Crunger (unregistered) in reply to the beard of the prophet
    the beard of the prophet:
    chris:
    As a number of people already have said, verbosity in itself isn't a bad thing.

    I beg to differ.

    Verbosity in itself is a bad thing, and typing effort is the least of the reasons. It makes code harder to read and understand,

    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.

  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    Well, Alex calls it a "side-by-side trial",
    Still missing a few DLLs. Furthermore the activation failures are missing from the logs.
  • Brad Ford (unregistered) in reply to nasch

    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.

  • Brad Ford (unregistered) in reply to nasch
    nasch:
    Brad Ford:
    It is not a good idea to have a name that describes what the table/stored procedure/method contains, or returns.

    The name of a table shouldn't describe what the table contains? What should they be called then? Table1, Table2?

    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.

  • Norman Diamond (unregistered) in reply to QJo
    QJo:
    El Guaco:
    This is just another case of the old axiom - There are only two hard things in Computer Science: cache invalidation and naming things.
    and off by one errors.
    No, off by one errors are easy.

    Oh wait, that's only true sometimes. It's easy to make two, but hard to make zero.

  • Brad Ford (unregistered) in reply to commoveo
    commoveo:
    nasch:
    Brad Ford:
    It is not a good idea to have a name that describes what the table/stored procedure/method contains, or returns.

    The name of a table shouldn't describe what the table contains? What should they be called then? Table1, Table2?

    Bah! Who needs tables, just store everything in one big flat-file.

    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 ;)

  • bog (unregistered) in reply to Walky_one
    Walky_one:
    Note: Everything depends on the definition of "Long".

    While very short, the following line would be even worse:

    x = f(y);

    My approach is:

    If you can't get the functionality of a line with a single glance you either have

    • Complex code that needs more attention
    • Inappropriate names (too long, too short, names that don't represent usage, ...)
    use the same principle as for commenting. You want the least possible detail to allow sufficient explanation while matintaing code readability (and you're allowed to abbreviate).

    A(B,C) = probably not good. RSAEncrypt(EncString, RSAParamList) = probably not bad. EncodeAccordingToAlgorithmCreatedByRivestShamirAddlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat(StringWhichNeedsToBeEncodedPreferablyUsingTheAlgorithmInventedByRivestShamirAdlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat, LongListOfParametersWithExcessiveNamesPreferablyListedIndividuallyButEachWithALongName) = perhaps a little ott....

  • bog (unregistered) in reply to bog
    bog:
    Walky_one:
    Note: Everything depends on the definition of "Long".

    While very short, the following line would be even worse:

    x = f(y);

    My approach is:

    If you can't get the functionality of a line with a single glance you either have

    • Complex code that needs more attention
    • Inappropriate names (too long, too short, names that don't represent usage, ...)
    use the same principle as for commenting. You want the least possible detail to allow sufficient explanation while matintaing code readability (and you're allowed to abbreviate).

    A(B,C) = probably not good. RSAEncrypt(EncString, RSAParamList) = probably not bad. EncodeAccordingToAlgorithmCreatedByRivestShamirAddlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat(StringWhichNeedsToBeEncodedPreferablyUsingTheAlgorithmInventedByRivestShamirAdlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat, LongListOfParametersWithExcessiveNamesPreferablyListedIndividuallyButEachWithALongName) = perhaps a little ott....

    although I mark myself down for inconsistency.

    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)

  • Mitch (unregistered) in reply to bog
    bog:
    Walky_one:
    Note: Everything depends on the definition of "Long".

    While very short, the following line would be even worse:

    x = f(y);

    My approach is:

    If you can't get the functionality of a line with a single glance you either have

    • Complex code that needs more attention
    • Inappropriate names (too long, too short, names that don't represent usage, ...)
    use the same principle as for commenting. You want the least possible detail to allow sufficient explanation while matintaing code readability (and you're allowed to abbreviate).

    A(B,C) = probably not good. RSAEncrypt(EncString, RSAParamList) = probably not bad. EncodeAccordingToAlgorithmCreatedByRivestShamirAddlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat(StringWhichNeedsToBeEncodedPreferablyUsingTheAlgorithmInventedByRivestShamirAdlemanAndPossiblyIndependentlyCreatedAtBletchleyParkBeforeThat, LongListOfParametersWithExcessiveNamesPreferablyListedIndividuallyButEachWithALongName) = perhaps a little ott....

    Won't work....you misspelt Adleman.....

  • (cs) in reply to Meep
    Meep:
    But you got rid of a table or two on the schema diagram, so it must be simpler! And practical!

    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.

  • MrOli (unregistered) in reply to Miriam
    Hey, those look just like the method names I see in Java!

    tbh, I never understood why so many people dislike long variable names.

    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.

  • Neil (unregistered)

    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.

  • Cheong (unregistered)

    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?

  • Richard Fbellarkeis (unregistered)

    There's "unreadably short", "concise", "verbose", and ENTERPRISE QUALITY.

  • Barf 4Eva (unregistered)

    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.

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    If a "LUB" is a company-known acronym, then it is better to name it "Lub".

    If it is an abbreviation, then Mixed case. If it is an Acronym the Upper Case. Some words start out as acronyms, but are later recognized as words (SCUBA/Scuba being perhaps the most common).

    These days, I'd suggest that Light Amplification by the Stimulated Emission of Radiation might be more common than Self Contained Underwater Breathing Apparatus...

  • smf (unregistered) in reply to Brad Ford
    Brad Ford:
    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,

    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

  • eric bloedow (unregistered)

    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.

Leave a comment on “The Name of the Rows”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article