• Andrew (unregistered) in reply to Code Slave
    Code Slave:
    Which works find until you hit the 256 character limit (assuming c++) and the compile can nolonger distinguish between veryLongStringOld and veryLongStringNew. Even more interesting results in some older versions of C where the limit was (as I recall) 32.

    Truly old C compilers/linkers required identifiers to be unique within the first 8 characters.

  • Bill (unregistered) in reply to rant64

    bool Underscores_are_close_enough_and_currently_supported_by_many_languages = true;

  • mbrown758 (unregistered)

    Man, I am old.When I was young we bitched about Cobol and stupidly verbose it was.....

  • mbrown758 (unregistered) in reply to Remko

    retard

  • mbrown758 (unregistered) in reply to JohnB

    You would never know if it "truly works", BECAUSE YOU COULD NEVER FUCKING READ IT DIPSHIT.

  • franz ferdinand (unregistered) in reply to JohnB

    [quote user="JohnB"]The real WTF: people complaining about naming conventions in an application that truly works.[quote]

    That is NOT TRWTF. The RWTF is that you are complaining about people criticizing code on a code-criticism site. Get lost.

  • John Sonmez (unregistered)

    I'll stand by this as decent code. Yes it is a little long in the names, but it is much much better than short names. MUCH better. The trouble with actual comments is they don't get updated. I must admit I would err on the side of this code than not descriptive enough. I would probably try to shorten it down just a tad, but that is readable code.

  • John Cowan (unregistered) in reply to rant64

    Algol 60 did();

  • Edward Royce (unregistered)

    For God's sake just write it in COBOL!

    The source code files will be smaller!

  • Xythar (unregistered) in reply to Shinobu
    Shinobu:
    I've seen a lot of code that I wish looked like this. I'll be honest, I use a lot of 1-char variable names myself, but I restrict those to local function variables, loop counters for example. Method names should be long and descriptive. The only reason that at first glance you're overpowered by the sea-of-letters-syndrome is that you can't use spaces in variable names. Now, you can use the non-breaking space, but that potentially creates visual ambiguity (<class> <identifier> vs. <identifier with a space in it>) and is harder to type. We need a good solution to the problem that doesn't have such drawbacks.

    It is possible to write code that doesn't go straight to either extreme. One character variable names and these variable names are equally bad.

  • Anachronda (unregistered) in reply to rant64
    rant64:
    We Need To Have Support For Spaces In Variables And Function Names = True;

    Easy peasy. Just do it in FORTRAN.

  • Humph (unregistered) in reply to AdT
    AdT:
    Even version control can be made obsolete by self-documenting variable names. Think of "longSizedInteger...FormerlyKnownAsDefaultSizedInteger..."
    Office lol, damn you!
  • Mads Bondo Dydensborg (unregistered) in reply to gallier2

    Danish is a sort of Germanic language too. Here is one "word" that we use to teach our kids.

    Sporvognsskidtskinneskraberoverassistentskastetemblemspudsemiddelsdåse.

    Translating each word it says Tram Dirt Removal Track Remover Super Intendent Cap Decoration Polishing Stuff Container.

    And, obviously, its the container where the superintendent in charge of keeping the tracks of the tram clean of dirt, keeps his polisher for the decoration on his cap.

    Its not a word used very often.

  • (cs) in reply to zidar
    zidar:
    AdT:
    Better names would be something like "defaultSizedIntegerVariableIndexingIntoEmployeesVectorWhichIsAVectorOfEmployeeRecordsEachOfWhichContainsPersonalInformationSuchAsFirstNameLastNameDateOfBirthAndRegisteredResidenceAsWellAsProfessionalInformationSuchAsJobTitleAndSalary_ThisVariableWasAddedByChiefSoftwareArchitectJohnDoeOnTheEveningOfWednesdayNovember12th2008RightBeforeDinner".
    This is actually the best variable name ever. just from reading this simple Integers name, i know what that loop does, what i can get from it, and what is the meaning of life.

    Actually, in order to incorporate the meaning of life, it should be called "defaultSizedIntegerVariableIndexingIntoEmployeesVectorWhichIsAVectorOfEmployeeRecordsEachOfWhichContainsPersonalInformationSuchAsFirstNameLastNameDateOfBirthAndRegisteredResidenceAsWellAsProfessionalInformationSuchAsJobTitleAndSalary_ThisVariableWasAddedByChiefSoftwareArchitectJohnDoeOnTheEveningOfWednesdayNovember12th2008RightBeforeDinner_42"

  • (cs)

    Now i understand VB.NET's 1023 characters limit o_o' they were fearing devs would use variable names longer than that if they didn't put a limit...

    ...holy s**t !

  • Zub (unregistered) in reply to AdT

    I had a good laugh at this.

  • ProgrammerThatNeedsToFitCodeLinesInto80Characters (unregistered) in reply to Xythar
    Xythar:
    ProgrammerThatNeedsToFitCodeLinesInto80Characters:
    I actually found that quite clear, at least in context:

    ... In other words: two-way synchronize changes, in case of conflict 'the shop' wins.

    IMO sheer length is not the WTF here. The only WTF I see is that names should describe what an operation means, not how it works.

    ...

    Yeah, and how long did it take you to figure out the process? Even if it only took a couple of minutes,

    More like a couple of seconds. Not really longer than with comments, except for reading slowdown caused by CamelCase.

    BTW: TRWTF is of course the website, which did not accept my FullyDescriptiveUserName. No way to include more detail or my bio.

    ... how are the long variable names better than a simple comment at the start describing exactly what you just said:

    // Synchronise changes between inventory and shop. In the case of a conflict, the shop wins.

    A one line comment before the code and you save yourself a whole lot of unreasonably long variable names, making the code more readable AND easier to understand.

    ... until that maintenance change, which makes the comment become out of sync with what the code does. And you always see the embedded information in every place where the identifier is used, so you have better chances to notice when implementation and intention diverge.

    Of course this requires a development environment where tools (autocompletion) make handling such names reasonably easy and where you can easily and reliably rename such things when their meaning evolves.

    Refactoring tools I have seen, don't update comments.

  • Design Pattern (unregistered) in reply to aoeu
    aoeu:
    "Constantinopolitanischerdudelsackspfeifenmachersgesellschafft!"

    (the bagpipe manufacturer's guild of constantinople)

    Well almost: "Constantinopolitanischerdudelsackpfeifenmachergesellschafft"

    But this one is a society while a gild would be: "Constantinopolitanischerdudelsackpfeifenmachergilde"

    aoeu:
    "Nihilistendynamittheaterkaestchenssprengungsattentaetsversuchungen!"

    (outrageous attempts by nihilists to blow up the strong box of a theatre with dynamite

    Absolutely not! Versuchung = seduction / temptation Versuch = attempt / experiment / trial

    So it would be more likely something like this: "Nihilistentheaterkaestchendynamitsprengungsattentatsversuch"

    But neither the former nor the latter is outrageous. Maybe adding a "markerschütternd" or a "himmelschreiend" somewhere?)

  • MarkF (unregistered)

    Speaking as someone who cut their teeth on C, many, many moons ago, I remember the joys of having to work with a basic text editor so limited in features that having single named variables such as 'i' was a non-starter - image the carnage of a simple "find i"...

    Very quickly got into the habit of double-naming, for instance 'ii'. Took me years to stop!

    Cheers

    Mark

  • G-Diddy (unregistered)

    Why do people always abbreviate "synchronisation" to "synch"? It should be "sync"!!

  • Mayhem (unregistered) in reply to G-Diddy
    G-Diddy:
    Why do people always do things different to me? It should be done how I like it!!
    FTFY
  • Josh (unregistered)

    Can't decide on this one. On one hand, this code is VERY descriptive. I can take one look at it and know what it is doing. This code will also be EXTREMELY easy to read when printed out with a black/white printer (try printing source code WITH multiline /**/ comments in black and white). Also, there's no additional comments to maintain in case the logic changes.

    On the other hand, the names are a little too long for my taste. Comments would be easy to spot with modern IDEs and syntax highlight. Comments would also help shorten the names of the functions.

    I don't know about the history of the OP's company (are the coders lazy? Were comments often out-of-sync?). For all I know, this may be the BEST solution for the company, obtained after decades of trials and improvements. Just like how some posters think the programmer took "self-documenting code" to the extreme, I think some posters are also taking what they learn from Uni to the extreme (all the axioms of software engineering, etc).

    To paraphrase Steve McConnell, a crude, working solution is better than an elegant solution that doesn't. Or Einstein's "make everything as simple as possible, but no simpler".

    I don't see this as a WTF. In fact, I'd very much like to meet this lead programmer, shake his hand, and listen to his thoughts on software development.

  • Cole (unregistered)

    That's not camelcase, that's a camel stampede.

  • (cs) in reply to Dan
    Dan:
    wow, those variables' names are as long as sandworms! [i mean, 55 comments and no Dune jokes?!? The man's called Stilgar for Shai Ulud's sake!]
    Why did my eyes just turn blue?
  • Adam (unregistered) in reply to AdT

    Decade of design. Obsolete, perhaps.

  • X (unregistered)

    My best shot, what I've found in code was the name of an interface:

    ICanBeAChildControl

  • David Ron (unregistered) in reply to Z

    Refactoring solves this little problem. At least in statically typed languages.

  • Bim Job (unregistered) in reply to Cole
    Cole:
    That's not camelcase, that's a camel stampede.
    Which seems to have encouraged a trollfest of absurd justifications. To quote MP:

    "Beethoven, Mozart, Chopin, Liszt, Brahms, Panties...I'm sorry...Schumann, Schubert, Mendelssohn and Bach. Names that will live for ever. But there is one composer whose name is never included with the greats. Why is it that the world never remembered the name of Johann Gambolputty de von Ausfern-schplenden-schlitter-crasscrenbon-fried-digger-dingle-dangle-dongle-dungle-burstein-von-knacker-thrasher-apple-banger-horowitz-ticolensic-grander-knotty-spelltinkle- grandlich-grumblemeyer-spelterwasser-kurstlich-himbleeisen-bahnwagen-gutenabend-bitte-ein-nürnburger-bratwustle-gerspurten-mitz-weimache-luber-hundsfut-gumberaber-shönedanker-kalbsfleisch-mittler-aucher von Hautkopft of Ulm?"

    It's actually quite readable without the CamelCase, which means that the lexer in the OP is to blame...

  • coder (unregistered) in reply to Z

    haha, YES!

  • Mike (unregistered)

    So, he's a Rod Johnson/Spring disciple....what of it? ;)

  • (cs)

    Wow. I've always argued that code that is self-commenting is always better than similar code that has comments. This totally proved me wrong.

  • Sachin Bhatt (unregistered)

    This kind of code is descriptive but does not tell you WHY the code was written. For that you need comments !!

  • Floored (unregistered)

    Wow, methods and constants a line long, but they still don't manage to say what they do. My question is how do you tell someone that long method names does not equal self documentation. I have a feeling this guy came from a school of thought that would consider

    // increment count by 1
count++;

    well documented code.

  • Sartan (unregistered)

    Not that it helps the original issues but using '_' instead of upper-casing separate words may help minutely.

    CodeThatDocumentsItselfSoWellItDoesNotNeedComments vs code_that_documents_itself_so_well_it_does_not_need_comments

    But that's just me.

  • (cs)

    Reminds me of the DBASE III days.. there were no such thing as function calls or subroutines... if you wanted to create a subroutine, you essentially created a new code file and called it.

    Which was fine, until you realized that DOS 3.2 didn't support more than 99 files open at a time, and after nesting about 5 or 6 files deep you were stuck.

    The eventual solution.... LOTS OF SPAGHETTI CODE in each FILE.

  • Dan M. (unregistered) in reply to Caffeine

    I'm really surprised he didn't name the enum more clearly.

    I would have half expected to see InventoryIntegrationDirectionEnumerators.<enum choice here>

    for each of the case choices.

    I must say, I like the idea... hate the implementation. Oh, and can't you compile the comments out of the code which begs the question of why not put comments in the code?

    I was hoping this was an article on someone developing some self-documenting module that could create some real documentation, you got me good!

  • Brendan Baldwin (unregistered)

    Reads like a legal document. Kind of a Lose-Lose situation.

  • Dopey (unregistered)

    I think I might know who wrote this, at least I've seen this exact kind of naming before, anyone here read "Beautiful Code"?

    captcha: modo

  • Marty (unregistered) in reply to rant64

    If(You.Sacarstic) Me.Laughing(); else Me.Punch(You);

  • msmbuzz (unregistered)

    You PC guys are unbelievable!! Us MAINFRAME guys started the meaningful field/data names which leads to uncommented code back in the 70's. At least you are finally realizing the need.

  • Ralph (unregistered)

    I don't think that code's as bad as you're making it sound.

    Your lead developer's combination of (long procedure names + no comments) is definitely a lot more helpful than (short procedure names + no comments).

    Whether his system is more or less helpful than (short names + good comments) depends on the quality of the comments.

    I imagine we can all agree that (long names + good comments) would be the best way to make code self documenting.

  • Q. Throckmorton Bibblewitz (unregistered)

    My god...

    It looks like... COBOL!

  • franz ferdinand (unregistered) in reply to Junkie
    Junkie:
    Dan:
    wow, those variables' names are as long as sandworms! [i mean, 55 comments and no Dune jokes?!? The man's called Stilgar for Shai Ulud's sake!]
    Why did my eyes just turn blue?

    Laughing my ass off broseph!

  • franz ferdinand (unregistered) in reply to Ralph
    Ralph:
    I imagine we can all agree that (long names + good comments) would be the best way to make code self documenting.

    I imagine that an English thesaurus and dictionary would go far in getting programmers to name their functions properly.

  • Correction (unregistered) in reply to AdT

    Correction: November 8, 2008 was a Saturday, not a Wednesday.

  • Correction (unregistered) in reply to Correction

    Re: CodeThatDocumentsItselfSoWellItDoesNotNeedComments 2009-09-23 09:53 • by AdT (unregistered)

    To you sir, I am correcting you. November 8, 2008 was a Saturday, not a Wednesday!!!!!!!!!!!!!!!! Open your ears man!

  • rood (unregistered) in reply to rant64

    Uh, no. This something we definitely do NOT need. We've been programming for a very long time without them, and sacrificing the principle of longest substring for parsing code is too heavy a cost to make in exchange for what exactly? Not having to think as hard when naming methods and variables? Ruby solves this problem with the underscore convention. Camel case isn't a terrible solution either.

    Man. I'd like to see somebody write a language that allows spaces in method and variable names.

  • Toby (unregistered)

    I have no fkn idea what anyone is talking about here.

  • shankhs (unregistered) in reply to AdT

    TheCodeNeedsDocumentation = TRUE; if(TheDeveloperOverConfident() OR HeWantsToMakeFunOfYou()) URScrewedTryingToUnderstandTheProgram(); else URScrewedTryingToUnderstandTheProgram();

  • (cs) in reply to rant64

    we_can_emulate_whitespace_with_underscores_and_have_clear_writing = true; # Unix programmer.

Leave a comment on “CodeThatDocumentsItselfSoWellItDoesNotNeedComments”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article