• Ziplodocus (unregistered)

    And there was evening, and there was mourning—the third normal form.

  • foo AKA fooo (unregistered)

    Dan, don't try to imitate Erik.

  • Squiggle (unregistered)

    I liked the bit where the perpetrator got lynched by an unruly mob at the end.

    captcha: abigo

    O

  • Code Jockey (unregistered)

    And what's the problem?

  • (cs) in reply to Code Jockey
    Code Jockey:
    And what's the problem?

    It hurts.

  • Miriam (unregistered)

    Hey, those look just like the method names I see in Java!

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

  • Walky_one (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.

    AutomationExportAutomationExportFieldLUByAutomationExportID = GetAutomationExportAutomationExportFieldLUByAutomationExportID(AutomationExportAutomationExportFieldLUByAutomationExportIDToRetrieveId);

    More clear now?

  • Walky_one (unregistered) in reply to 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, ...)
  • Rodnas (unregistered)

    And has anyone noticed that we are back to the frist normal form of supplying comments to TDWTF articles.

    Change is never a good thing

  • faoileag (unregistered) in reply to Miriam
    Miriam:
    Hey, those look just like the method names I see in Java!
    This guy was sure AbstractSingletonProxyFactoryBean was not the longest classname in Java; and he was right!
    Miriam:
    tbh, I never understood why so many people dislike long variable names.
    Same here - I prefer verbosity to forced brevity.

    However, when the length of the variable name and the length of the method name each are above, say, 40 characters, the code tends to become a tad bit unreadable.

  • Vitani (unregistered)

    Pssh, that's nothing. In a project I work with we have the same three laws of progotics, which has lead to a table called "ProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField" which, naturally, has a stored procedure named "spProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField_GetByProjectDisciplineProjectDocGenTypeFormatID"

  • (cs) in reply to Vitani

    At least they're not running an Oracle database.

  • faoileag (unregistered) in reply to Rodnas
    Rodnas:
    And has anyone noticed that we are back to the frist normal form of supplying comments to TDWTF articles.
    Well, Alex calls it a "side-by-side trial", so we will probably still have a couple of articles where the comment system is CS ahead of us.

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

  • Chaarmann (unregistered)

    I think the rules are ok. I can see the advantage when you can sort by table name when having dozens of stored procedures for each of your dozens of tables.

    But if you apply the rule to bad table names and fields, then not the rule is guilty, but the bad table name and their fields. Usually, the table name should not be repeated in the name of the table fields. This is bad:

    Table: AutomationExport fields: AutomationExportFieldLUB, AutomationExportID

    So correct it by renaming fields to: FieldLUB, ID

    Now applying the rule: GetAutomationExportFieldLUBByID

    By the way, what's the meaning of "FieldLUB"? If a "LUB" is a company-known acronym, then it is better to name it "Lub". The same goes for "Id". If there is no other type of LUBs than a "field"-LUB, you can omit the word "field". That gives us:

    Table: AutomationExport fields: Lub, Id

    Now applying the rule: GetAutomationExportLubById

    I would refine the rule: if there are more than 2 fields returned then you can give a goup name instead: Example: employee-table that holds first name, middle name, last name, street, city, country, zip, status, salary, ID, and you want to retrieve all the address data, then you can use: getEmployeeAddressById or getEmployeeFullNameById instead of: getEmployeeFirstNameMiddleNameLastNameById or getEmployeeStreetCityCountryZipById.

    You can also split up the employee table and put the name data in a second table. tableName: employeeName fields: first, middle, last, maiden, title, ID

    Now you can access by: getEmployeeNameFirstLastById

    This way you can say: if the stored procedure name gets too long, you have a bad table design!

  • (cs) in reply to Chaarmann
    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).

  • mister stick (unregistered) in reply to Chaarmann

    the Microsoft standard is that acronyms and initialisms are treated as words, that is lowercase with a leading capital where appropriate. i use it because i find that PcmciaCode is more readable than PCMCIACode.

    Chaarmann:
    Table: AutomationExport fields: AutomationExportFieldLUB, AutomationExportID

    So correct it by renaming fields to: FieldLUB, ID

    hmm. what if FieldLub is used elsewhere in the system? or if the field is "Account" and the table "Bank"? how do you differentiate Bank.Account from Wtf.Account? doesn't that break Nth normal form?

  • Jibble (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.

    Have you ever read the story "Goldilocks and the Three Bears"...?

  • Sven (unregistered) in reply to TheCPUWizard

    Radar, Modem, ... I'm sure there are more

  • Your prose is WAY to fucking purple. (unregistered)

    Are you guys just trying to troll your regulars into non-existence?

  • Naturschutzgebiet (unregistered)

    The practice seems oddly German.

  • faoileag (unregistered) in reply to Naturschutzgebiet
    Naturschutzgebiet:
    The practice seems oddly German.
    That would explain why dict.cc is unable to find a translation for "Nominalkompositum".

    Captcha: usitas - chaining nouns is not in widespread usitas.

  • (cs)

    Sup dawg, I heard you like AutomationExport

  • fatfacemcfattypants (unregistered) in reply to faoileag
    faoileag:
    Miriam:
    Hey, those look just like the method names I see in Java!
    This guy was sure AbstractSingletonProxyFactoryBean was not the longest classname in Java; and he was right!
    Miriam:
    tbh, I never understood why so many people dislike long variable names.
    Same here - I prefer verbosity to forced brevity.

    However, when the length of the variable name and the length of the method name each are above, say, 40 characters, the code tends to become a tad bit unreadable.

    Long variable names are harder to remember/type but can follow a pattern to compensate. The problem is you really need to adhere to this pattern well. Having a pattern makes thing predictable, organisable, easier to automate, and so on. If you can remember rules for naming you can use this to work out what names refer to/could be if you read/are writing them. Actually this is often not possible if you let a human choose what they believe is linguistically optimum each time. You cannot necessarily anticipate as easily this way. Consistency might give you a better heuristic.

    Naming tables well can be very difficult. This is one way to compensate, it can more often be clear what to name certain complex tables that don't quite represent one thing. For example, you might decide to call your intersection tables TableATableBRelationship. We might have a lot of words for each thing but words for relationships between things are tricky. It's not always the case a single word can represent the whole relationship between the pair (and the relationship type) or even the pair.

    This kind of pattern is also useful because it can make a kind of a stronger contract between function name and what a function does. However it doesn't work well for weird cases.

    I've used this same pattern in an automated sql model builder. There's a bit of a difference between asking a human to do it and a machine but generally my rules for humans. For a human finding good names is one thing, but for a machine, just give it up. For my automodel this works brilliantly and by functions look a lot like the above. Although it outputs function names, it's enough for me to know the table structures because the consistent naming convention creates a direct mapping to these.

    I don't have names as long as:

    GetAutomationExportAutomationExportFieldLUByAutomationExportID though. I expect there to be rules for making exceptions or aliases where names become too long. Those cases warrant some extra time to think about an effective name. Still, I have inherited legacy code with one function that was more than 100 characters long describing everything it did in detail (ie get_user_from_database_where_id_is_user_id_or_return_null_etc). Perhaps frustration caused him to do this or otherwise he thought it a clever way to not Doc the function.

    Apart from that I think the developer in the article really isn't that bad. He looks like he's ahead as most projects have no naming convention at all. Overly strict enforcement might be a problem. He could be tired of people trying to give a short concise names to functionality and making the situation worse. I have seen people sit there for an hour working out what to name a function or variable.

    I have many such rules and I am quite strict. I use _ rather than camel case in my DB structure, prefix tables, yet do not have table names more than 40 characters. I think the longest few are a bit over 30. In the code, I don't thing there are many functions much more than 20 characters.

    Summary...

    This discussion belongs under why human language sucks category.

  • fatfacemcfattypants (unregistered) in reply to fatfacemcfattypants
    • for humans are roughly the way
  • fatfacemcfattypants (unregistered) in reply to fatfacemcfattypants

    argg

    • same
  • db (unregistered)

    Address can have only country, so what the purpose in AddressCountryTable table?

  • Meep (unregistered)
    And there was evening, and there was morning—the third normal form.

    Nothing in the article is remotely related to normalizing.

    But let's consider an example where some asshole decides, "let's denormalize these tables for speed."

    Then a simple "INSERT (serial, widget, color) VALUES (?, ?, ?)" becomes five or six insertions into various places.

    And there are odd bugs due to race conditions that languish on the bug tracker. So users waste huge amounts of time with workarounds.

    And you can't express the internal constraints with a few foreign keys, so it's all enforced throughout the application.

    Thus refactoring code becomes an arduous process of fixing copy-pasta, generating more bugs, fixing those, etc.

    But you got rid of a table or two on the schema diagram, so it must be simpler! And practical!

  • F (unregistered) in reply to Vitani
    Vitani:
    Pssh, that's nothing. In a project I work with we have the same three laws of progotics, which has lead to a table called "ProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField" which, naturally, has a stored procedure named "spProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField_GetByProjectDisciplineProjectDocGenTypeFormatID"

    I'm sure there's a typo in there, but I can't find it again to tell you where it is.

  • anonymous (unregistered) in reply to F
    F:
    Vitani:
    Pssh, that's nothing. In a project I work with we have the same three laws of progotics, which has lead to a table called "ProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField" which, naturally, has a stored procedure named "spProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField_GetByProjectDisciplineProjectDocGenTypeFormatID"

    I'm sure there's a typo in there, but I can't find it again to tell you where it is.

    lead vs. led

  • eman_ruoy (unregistered)

    Heaven help the person that tries some recursive linking/references

  • Andrew (unregistered) in reply to Chaarmann

    Cannot agree more with this one.

    Given a human had hard time to understand more than seven things at a time, have seven different words in an identifier is overboard.

    Names are ultimately abstraction of what the table/procedure does, it is okay to summarize, going overboard with naming convention to provide information reminds me of Hungarian notation which I hate.

    What is m_pptm? A member variable which is a pointer to pointer of the transaction manager ... kill me with that one.

  • Umberto Eco (unregistered)

    Were there priests involved?

  • Andrew (unregistered) in reply to Walky_one

    I kind of like long variable name if it is not too long.

    I guess this depends on how wide your screen is, if you need to scroll that is definitely not good.

    I use a simple heuristic called printing test. If I could print to code on a paper in landscape mode without having to wrap the line, it is probably not too long.

  • chris (unregistered)

    As a number of people already have said, verbosity in itself isn't a bad thing. Especially these days when you have an IDE to do most of the work for you (completion etc). Sure, there's a limit to when it becomes ridiculous, but the point of the article seems to be that having a naming scheme that may lead to long names is bad. I disagree. (Since it is databases involved, perhaps there's some domain-specific thing why verbosity is bad. I don't know the first thing about databases; my comment is more general with code development)

  • Pock Suppet (unregistered) in reply to Vitani
    Vitani:
    Pssh, that's nothing. In a project I work with we have the same three laws of progotics, which has lead to a table called "ProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField" which, naturally, has a stored procedure named "spProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField_GetByProjectDisciplineProjectDocGenTypeFormatID"
    TRWTF here is prefixing the stored procedure name with "sp", as if that wouldn't be obvious from the context. On the other hand, the company where I work prefixes everything with the company prefix, even in databases for custom internal applications that never interact with the outside world.
  • anonymous (unregistered) in reply to Pock Suppet
    Pock Suppet:
    Vitani:
    Pssh, that's nothing. In a project I work with we have the same three laws of progotics, which has lead to a table called "ProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField" which, naturally, has a stored procedure named "spProjectDisciplineProjectDocGenTypeFormatDocRevisionMetaField_GetByProjectDisciplineProjectDocGenTypeFormatID"
    TRWTF here is prefixing the stored procedure name with "sp", as if that wouldn't be obvious from the context. On the other hand, the company where I work prefixes everything with the company prefix, even in databases for custom internal applications that never interact with the outside world.
    Our Access databases were built by someone who held a somewhat tenuous grasp on the concept of Hungarian nomenclature. Thus we have tblNames, frmNames, tblNames Subform, qryNames, tblNames Query. By the way, tblNames Query is a report. Bet you didn't see that coming.
  • Alex Godofsky (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.

    com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

  • (cs) in reply to Pock Suppet
    Pock Suppet:
    On the other hand, the company where I work prefixes everything with the company prefix, even in databases for custom internal applications that never interact with the outside world.
    At least you're prepared for when you're taken over by another company!
  • OldCoder (unregistered) in reply to Alex Godofsky
    Alex Godofsky:
    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.

    com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

    What? No buffaloes?

  • Charles (unregistered)

    Of course, Oracle has a 32-character object name limit.

  • Scourge of programmers. (unregistered)

    Sometimes it is useful to have long file names and avoid developers groping in the dark to find the right function for the job.

  • (cs) in reply to Your prose is WAY to fucking purple.
    Your prose is WAY to fucking purple.:
    Are you guys just trying to troll your regulars into non-existence?
    No, that's what Discourse is for.
  • the beard of the prophet (unregistered) in reply to chris
    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, variables more difficult to recognize and distinguish. Any naming convention forcing long names must make up for these costs.

    The best names are short, concise and descriptive. Long, descriptive names may be better than non-descriptive names of any length, but they are still a compromise.

  • clydesdale (unregistered) in reply to mister stick
    mister stick:
    the Microsoft standard is that acronyms and initialisms are treated as words, that is lowercase with a leading capital where appropriate. i use it because i find that PcmciaCode is more readable than PCMCIACode.
    Chaarmann:
    Table: AutomationExport fields: AutomationExportFieldLUB, AutomationExportID

    So correct it by renaming fields to: FieldLUB, ID

    hmm. what if FieldLub is used elsewhere in the system? or if the field is "Account" and the table "Bank"? how do you differentiate Bank.Account from Wtf.Account? doesn't that break Nth normal form?

    Hmm. The English standard is to capitalize the first word of sentences, but, you know, to each his own.

    (As a rule, I detest comments which mention the captcha (including this one), but my captcha was "conventio" -- just too apropos to ignore. Sorry. Yes, I am.)

  • El Guaco (unregistered)

    This is just another case of the old axiom - There are only two hard things in Computer Science: cache invalidation and naming things.

  • Developer Dude (unregistered)

    So, if you change the name of the foreign key, add/remove a foreign key, you have to change the name of the table??

  • (cs) 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);

    Well, there's your problem: you got the axes backwards. Everyone knows that y= f(x), so x = finverse(y)

  • Ziplodocus (unregistered) in reply to Developer Dude
    Developer Dude:
    So, if you change the name of the foreign key, add/remove a foreign key, you have to change the name of the table??

    What happens if there are multiple foreign keys in the table?

  • (cs) 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, ...)

    That line is extremely easy to understand.

    Try something like this:

    var q = qu(o);
  • ih8u (unregistered) in reply to clydesdale
    clydesdale:
    mister stick:
    the Microsoft standard is that acronyms and initialisms are treated as words, that is lowercase with a leading capital where appropriate. i use it because i find that PcmciaCode is more readable than PCMCIACode.
    Chaarmann:
    Table: AutomationExport fields: AutomationExportFieldLUB, AutomationExportID

    So correct it by renaming fields to: FieldLUB, ID

    hmm. what if FieldLub is used elsewhere in the system? or if the field is "Account" and the table "Bank"? how do you differentiate Bank.Account from Wtf.Account? doesn't that break Nth normal form?

    Hmm. The English standard is to capitalize the first word of sentences, but, you know, to each his own.

    (As a rule, I detest comments which mention the captcha (including this one), but my captcha was "conventio" -- just too apropos to ignore. Sorry. Yes, I am.)

    I always use as much FieldLube as possible.

    As a rule, I detest replies to comments (including this one), but the comment to which I am replying was just to apropos to ignore.

Leave a comment on “The Name of the Rows”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article