• (disco)

    What kind of name is "Jonathon"?

  • (disco)

    So much rage in this article.

  • (disco)

    The useless comments don’t surprise me. At work, we use a code checker which insists on having at least a comment for each function. So every int get_something_count(void) gets a redundant comment.

  • Mnemonic Carrier (unregistered)

    This isn't the frist time I've seen such redundant code.

  • (disco) in reply to aliceif
    aliceif:
    What kind of name is "Jonathon"?

    According to urban dictionary:

    Jonathon. an amazing guy, who is funny and social. he deserves the best in life and deserves to be with an amazing girl.

  • (disco) in reply to aliceif

    A mis-spelt one. Should be Jonathan.

  • (disco)

    This is enterprise code already. Encapsulated and defensive at its best. The Guid.NewGuid() method could be deprecated/removed in the future and all of our code would break!

    Bonus points on adding an interface so we can decouple it for mocking.

  • (disco)

    It makes sense to create that damn GUID service. This way you can mock it in tests. Have fun mocking static methods :)

  • (disco)

    The value of XML comments is not in the context of the code, but in the help files what are generated from them. Since these files can have multiple content sources (e.g. Examples) that are processed into pages [just like MSDN] the only way to evaluate the usefulness is by being presented with the final processed page and analysis performed from the context of someone who has that documentation along with the compiled code (i.e. DLL)

    Even the act of wrapping a Guid may not be a WTF... There are many different types of Guids and algorithms for generating them. The .NET provided method is only one of many, and there are definitely cases where it is not the most appropriate type.

  • (disco)

    "The GuidService implements the IGuidService contract, and contains a method NewGuid which returns a Guid generated by the static NewGuid method on the Guid class" - Reminds me of THHGTTG: When I press this black switch that's labelled in black on a black background a black light lights up black to let me know I've done it.

  • (disco)

    // This is a comment on the article.

  • (disco)

    not enough entterprise.

    ther eneeds to be at least 4 more levels of indirection in there, and the result should be returned in XML unless an optional parameter is passed in which case it should be returned in malformed JSON

  • (disco) in reply to Matt_Westwood

    You have to take that up with the submitter- I spelled the name like it was in their submission.

  • (disco)

    Let’s start with the comments. Look at those comments. They provide no information. Why should they?

    They're not just comments, they're documentation comments, which is completely different. It's not uncommon for documentation comments to state the obvious (although in this case the author could probably have put a little more effort in them).

    The class provides no functionality, either! It’d be one thing if this service was an attempt to patch the fact that JavaScript has no native GUID functionality, but this code isn’t called by JavaScript- it’s consumed by other services in Business.Common

    It may seem useless (because the code that uses it could call Guid.NewGuid() directly), but it's actually useful for unit tests. You can replace the IGuidService with a mock that will return a specific GUID for testing purposes (similarly, you might want abstract the current time behind an interface to test a scenario at a given fixed time).

    So, on the whole, this snippet is probably a bit over-engineered, but it's not really a WTF.

  • (disco)

    While the name is both clear and accurate, I hate it, because it immediately tells you that this service PROVIDES NOTHING.

    That's not a bug. It's a feature.

  • (disco)

    I agree that the XML Documentation Comments (simply referred as "comments" in the article) are useless, but not really a WTF since it is how the XML Documentation Comments should be used for. Just like most Javadoc comments.

    Like what?

    /** Sets the name of the monkey.
 * @param name - the monkey's name.
 */
public void setMonkeyName(String name) {
    // *snip*
}
  • (disco) in reply to Matt_Westwood
    Matt_Westwood:
    A mis-spelt one. Should be Jonathan.

    Not necessarily, my partner's brother is a 'Jonathon'. I'm a 'Jonathan' and I agree that's the only proper spelling ;)

  • (disco) in reply to aliceif
    aliceif:
    What kind of name is "Jonathon"?

    It's a fairly common alternate spelling. After a while, you just stop caring about such things other than to get them right according to the owner of the name…

  • (disco)

    I don't understand the submitter's problem with the namespace "Business.Common". Seeing the full namespace Business.Common.Services, my first thought would be a library supplying business logic, available in both client and server code, and that the classes in here are services. Where's the WTF? In fact, looking at my current work project, I see:

    • "bl" packages for business logic related code
    • "common" for classes that will be present in both client and server jars (as well as "client" and "server" packages, for classes that will only be present in one or the other)
    • "servlets" for servlets, "services" for services, "db" for some database mapping and hibernate stuff, etc.

    For large projects, it makes sense to properly organize the code into sane namespaces.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    The value of XML comments is not in the context of the code, but in the help files what are generated from them. Since these files can have multiple content sources (e.g. Examples) that are processed into pages [just like MSDN] the only way to evaluate the usefulness is by being presented with the final processed page and analysis performed from the context of someone who has that documentation along with the compiled code (i.e. DLL)

    A class named "GuidService" does not benefit from the description "Guid service", regardless of the output context. The other comments, by the way, are copy-and-paste from MSDN's Guid.NewGuid page, highlighting the utter pointlessness of this "service".

    TheCPUWizard:
    Even the act of wrapping a Guid may not be a WTF... There are many different types of Guids and algorithms for generating them. The .NET provided method is only one of many, and there are definitely cases where it is not the most appropriate type.

    If we want a new type of Guid other than the .NET-provided one, then why have we baked into the signature a return type of... um... the .NET-provided one (System.Guid)?

  • (disco) in reply to aliceif
    aliceif:
    What kind of name is "Jonathon"?

    Probably a first name. Goodluck.

  • (disco) in reply to nmclean
    nmclean:
    If we want a new type of Guid other than the .NET-provided one, then why have we baked into the signature a return type of... um... the .NET-provided one (System.Guid)?

    Good point, at the end you're testing .Net GUID. Would made sense with a custom GUID class which extends/wraps the platform one.

    But we have to agree it's not such a big WTF.

  • (disco)

    dkf deceived me in believing that Remy doesn't put cornify in CodeSOD articles, but I see it here. I'm disappointed by the small amount of hidden commentary by him in the recent articles though.

  • (disco) in reply to nmclean

    YHBT. YHL. HAND.

    (Apparently acronyms are a barrier to reading.)

  • (disco) in reply to Nprz
    Nprz:
    dkf deceived me in believing that Remy doesn't put cornify in CodeSOD articles, but I see it here.

    He didn't used to. (I still want a cornify plugin for DC for randomness value. It's a good way to make a drab article much more interesting.)

  • (disco) in reply to Eldelshell
    Eldelshell:
    But we have to agree it's not such a big WTF.

    The big WTF is having an actual service for this (as opposed to a mockable class, which makes a little sense). Because only one system in the whole enterprise has any chance of knowing how to issue actual GUIDs and the others all have to delegate to it to avoid duplicates…

  • (disco) in reply to aliceif

    A boy I liked in 8th grade named Jonathon jumped off a balcony and missed school for 3 months while they rebuilt his shattered ankle. When I asked why he did it just got this weird smile and “felt like I was flying...”

  • (disco)

    This function was meant to return a comment, but no comment was generated.

  • (disco) in reply to AwesomeRick

    It does make sense to organise code into namespaces, but it helps to engage brain when selecting the names. Using complete generics could lead to future namespace clashes. Hence the sensible Java convention.

    (My favourite still remains the bouncycastle cryptography libraries).

  • (disco) in reply to RFoxmich

    Seen in code: // This is the comment

  • (disco) in reply to Developer_Dude

    Isn't that auto-inserted by one version of Netbeans?

  • (disco) in reply to nmclean
    nmclean:
    If we want a new type of Guid other than the .NET-provided one, then why have we baked into the signature a return type of... um... the .NET-provided one (System.Guid)?
    The phrase "different type of Guid" doesn't mean a Guid of a different form, it means that a different algorithm is used to create it. Yes, it's redundant with the next clause in his sentence. See [RFC 4122][1].
  • (disco)

    Does Jonathon write unit tests using a mocking library? Does Jonathon use Stylecop? Perhaps not?

  • (disco)

    The real WTF here is not knowing the difference between Java and Javascript.

  • (disco) in reply to SkylerL
    SkylerL:
    The real WTF here is not knowing the difference between Java and Javascript.

    Well, duh, anyone can see it's the last 6 letters.

  • (disco)

    Who stole this code from my company?

  • (disco) in reply to AwesomeRick
    AwesomeRick:
    I don't understand the submitter's problem with the namespace "Business.Common". Seeing the full namespace Business.Common.Services, my first thought would be a library supplying business logic, available in both client and server code, and that the classes in here are services. Where's the WTF? In fact, looking at my current work project, I see:
    • "bl" packages for business logic related code
    • "common" for classes that will be present in both client and server jars (as well as "client" and "server" packages, for classes that will only be present in one or the other)
    • "servlets" for servlets, "services" for services, "db" for some database mapping and hibernate stuff, etc.

    For large projects, it makes sense to properly organize the code into sane namespaces.

    It generally leads to the anti-pattern of just throwing everything business-related into Business.Common and creating a God object.

  • (disco) in reply to Arantor

    ߯ªJava?

  • (disco)

    OP does no unit tests nor are there any documentation files for his code. OP, come work in a dev shop that has continuous integration implemented with teams across multiple contents and lets see how your tune changes. :smiley:

  • (disco) in reply to AwesomeRick

    Whenever I see anything names common or generic I know that the code that lies within is a load of crap. Both those namespaces are telling me that the code it is a dumping ground for poorly thought out code.

  • (disco) in reply to ben_lubar
    ben_lubar:
    ߯ªJava?

    You're just the kind of person who would put Unicode characters into a variable name just because you can, aren't you?

  • (disco) in reply to FrostCat

    Obligatory: http://what.thedailywtf.com/t/apple-swift/579/55?u=aliceif

  • (disco) in reply to aliceif

    Perfect truncation in that one-box.

  • Pentester (unregistered)

    Sniff

  • (disco)

    It’d be one thing if this service was an attempt to patch the fact that JavaScript has no native GUID functionality

    Since when can Java be called from JavaScript?

  • (disco) in reply to tom103
    tom103:
    It may seem useless (because the code that uses it could call Guid.NewGuid() directly), but it's actually useful for unit tests.

    Except there's just about no value whatsoever in mocking out the GUID for testing.

  • (disco) in reply to nzifnab

    That's C#, not Java, and it's very common to call WCF services (which look basically like this) from JavaScript.

  • (disco) in reply to AwesomeRick
    AwesomeRick:
    "common" for classes that will be present in both client and server jars (as well as "client" and "server" packages, for classes that will only be present in one or the other)

    Except that's not what people will think "common" means. They'll start throwing anything and everything in there, when in reality there is usually a much better place for it. And for organization sake, why would anyone care that the same class is used on the server and the client? That communicates very little, if anything, about what the actual classes do or how they're used.

  • (disco) in reply to nzifnab
    nzifnab:
    Since when can Java be called from JavaScript?

    I would swear that back in the day Java applets in a web page were scriptable.

  • (disco) in reply to FrostCat

    I was simulating the process of "get the last 6 letters of "Java"". Although I admit that's seven letters, it didn't look right without all three of the random unicode symbols.

Leave a comment on “Enterprise GUID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article