• (cs)
    Alex Papadimoulis:

    #define begin {
    #define end   }
    begin      
      if(buttonCounter == 30) {
        debounceButtons();
        buttonCounter = 0;
      }  
      else {
        buttonCounter++;
      }                  
    end 
    

    I wonder what was the purpose of declaring macros to replace curly braces, maybe they were making sure that everyone that reads this understands that the program starts from the start and ends at the end? Hehehe :P

  • (cs) in reply to eth0
    eth0:
    Alex Papadimoulis:

    #define begin {
    #define end   }
    begin      
      if(buttonCounter == 30) {
        debounceButtons();
        buttonCounter = 0;
      }  
      else {
        buttonCounter++;
      }                  
    end 
    

    I wonder what was the purpose of declaring macros to replace curly braces, maybe they were making sure that everyone that reads this understands that the program starts from the start and ends at the end? Hehehe :P

    I've actually seen that a couple of times. Usually it's people that learned Pascal first and then C/C++. I guess when the lizard brain takes over, you run back to what you know.

  • Alex (unregistered)

    They could at least be consistent...

    begin      
    if(buttonCounter == 30) begin
    debounceButtons();
    buttonCounter = 0;
    end
    else begin
    buttonCounter++;
    end
    end

  • (cs)

    I've seen such begin and end macros in use with students beginning C programming, as it is sometimes hard to distinguish between a curly bracket and parenthensis when one does not have much experience with C.  In addition, it would make it a little easier to read/comprehend to the C initiate.

  • andrey (unregistered) in reply to Ordog163

    C isn't the only language that uses curly braces.  When I took my first C++ course a couple of years ago, I'd say that pointers gave me far more trouble than the parenthesis or curly braces.  pascal.h does NOT make the code any easier to read - especially when used sporadically.  That's probably the reason why some new languages don't even support C-style macros. 

    Even though I think it's a little unfair to bash student's code (being a student myself), Cornell students should know better than to use magic numbers :)
    After all, it's only a short step from a few literal loop counters to something like this: http://www.thedailywtf.com/forums/22742/ShowPost.aspx


  • Marco (unregistered) in reply to eth0

    In college, I once turned in a C-program that used begin/end macros, because the professor didn't know C (but did know Pascal).

  • (cs)

    If Not objUser.IsAdministrator Then
    Response.Redirect "anotherpage"
    End If

    This is oh so familiar ASP code. Our company has such special exceptions (usually keying off of a company ID) all over the place. Many times you don't even realize a menu existed and/or was effected by a change because it only shows up for company 42 when using option 17 and of course "It worked when *I* tested it".

  • (cs) in reply to EsotericMoniker

    Once again I feel sorry for folks who have to maintain languages without braces or parens around conditional expressions, or with "then".

    I like writing Delphi but its horrible syntax is actually throwing me into C++ and C#'s arms.

     

  • Ross Presser (unregistered) in reply to rogthefrog

    Braces and parens around conditional expressions are syntactic sugar.  If you feel sorry for users of languages which lack them, then you must be a syntactic diabetic.

    Seriously, though, people can get used to damn near anything, and still be productive. It just takes time and will. People wrote better stuff in FORTRAN-77 than you will EVER write. Deal.

  • Anon (unregistered) in reply to Ross Presser

    Bullshit.  In theory, syntax doesn't matter.  We experienced programmers can pick up just about any language in a few days or weeks (passably well) even if the syntax is wildly different, right?

    But in practice, a nicer syntax means fewer bugs.  It also means faster development.  It's easy to see this; just take it to the logical extreme:

    new function foo returns type integer takes arguments x with type integer
    begin the function's block
      return the value x multiplied by x
    end the function's block

    vs.

    int foo(int x) {
      return x*x;
    }

    The first one will drive you crazy.  You'll get frustrated, miss subtle bugs, etc.  The second is not too bad.

    You can continue your argument, of course; I won't respond further.  But others: don't let yourself be deceived into thinking that all programming languages are equal just because they're all Turing complete or because an experienced programmer can do great things with all of them.  Some languages are better than others, and part of the reason is a syntax that makes development easier.

  • Ross Presser (unregistered) in reply to Anon

    Bullshit yourself.  While you do have a point, it is not as important as you make it out to be. IMNSHO, there are far more poor programmers, far too many in fact, who are enabled to program poorly by good languages, than there are good programmers hindered by bad languages.

  • (cs) in reply to Ross Presser

    I'm not sure if this was intended to be a WTF, but I'll note that FlexWiki does something like the substitution of Application("siteroot") and it's a royal PITA. Why? Because our server has multiple names depending on whether you invoked it from inside or outside the firewall. Or if you invoked it by IP address. Or if you used HTTPS rather than HTTP. The choice of the first user since the output cache was last invalidated then seems to be kept in the output cache, which isn't varied on the way it was invoked. Result, you get duff links in the page.

    Just use a relative URL. Much safer.

  • Sparr (unregistered) in reply to rogthefrog

    You should try out some languages with mandatory indenting, FAR easier to read than any sort of block markers, whether they are begin/end or {/}

  • Marc (unregistered) in reply to Sparr
    Anonymous:
    You should try out some languages with mandatory indenting, FAR easier to read than any sort of block markers, whether they are begin/end or {/}

    A total sweedack from me. [Imagine the 'thumb up' emoticon here. Inserting doesn't work for me with Opera 8.0/Linux]

  • (cs) in reply to Ross Presser
    Anonymous:
    Bullshit yourself.  While you do have a point, it is not as important as you make it out to be. IMNSHO, there are far more poor programmers, far too many in fact, who are enabled to program poorly by good languages, than there are good programmers hindered by bad languages.


    Although I agree with you, I think this is due more because good programmers tend to gravitate towards good languages, and poor programmers don't have enough knowledge/experience/drive/interest/initiative/permission/schutzpa/whatever to discriminate between them.

        -dZ.
  • andrey (unregistered) in reply to Ross Presser

    But then again, even the assembly language is 'syntactic sugar' for 1s and 0s that the machine works with.

  • Aristotle (unregistered) in reply to andrey

    “Real programmers don’t use editors. Real programmers use cat.” ?

  • (cs) in reply to DZ-Jay
    DZ-Jay:
    Anonymous:
    Bullshit yourself.  While you do have a point, it is not as important as you make it out to be. IMNSHO, there are far more poor programmers, far too many in fact, who are enabled to program poorly by good languages, than there are good programmers hindered by bad languages.


    Although I agree with you, I think this is due more because good programmers tend to gravitate towards good languages, and poor programmers don't have enough knowledge/experience/drive/interest/initiative/permission/schutzpa/whatever to discriminate between them.

        -dZ.


    Isn't it actually more likely that good programmers would gravitate to those languages that best express the concepts the program/project is meant to deal with? Heuristics in assembler would be as silly as fluid dynamics in Visual Basic. Both can be done by a sufficiently motivated (or sufficiently self-loathing) programmer, but neither is a particularly good idea from an expressiveness point of view -- assembler addresses the machine directly, but has no way to express the "big idea", and VB has no "matrix mashing" functionality, leaving you at the mercy of Variants. Is there anyone here who'd really like to take a stab at creating a UI environment in an extended APL? There's no sense trying to talk about the subtleties of a snowstorm in Togalog or describe the difference between this year's monsoon and last year's in Inuktatuk.

    That being said, there's a lot more to a language's syntax and expressiveness than the characters used to delimit blocks. Curly braces are neither intrisically superior to or inferior to near-natural-language delimiters. Neither is more readable or more maintainable than the other, provided that the person doing the reading or maintaining knows the language at hand. (Frankly, I find the "logical extreme" example more readable than the C-style example, except that I wouldn't want to have to type that much and that it's unclear from the example syntax how arguments would be supplied to the function. It's unlikely that basic arithmetic operations would be replaced by text descriptions of the operation in any language that natively supports arithmetic, so I'll let the illogical line slide.)

    Getting back to the WTF -- aside from writing readable C for a Pascal-speaking professor in a classroom exercise (marks are marks after all), there's no good excuse for macro-ing one language to look like another. All you get is code that can't be properly maintained by a unilingual expert in either language.
  • (cs) in reply to Anon

    It's possible to have a language with (almost) no syntax: it's called LISP (not strictly true, but close: LISP's syntax is basically a representation of the parse tree - that is, the data structure your compiler/interpreter creates once it's read all your program source and started trying to understand it.  The advantage of this is that you can control your compiler/interpreter in a way unknown to any but the most extreme Forth programmer).

    If you want syntax, though, I disagree that Delphi's is particularly bad; it's actually quite elegant, but it's different from the C family, and like Vegemite and nasal sex, it's an acquired taste.  The only thing I really hate about it is that a statement like this will fail to compile:

    if X < 0 or X > 9 then ErrorMessage('Please enter a digit');

    In Pascal/Delphi, the boolean operators and and or have higher precedence than the comparison operators, so you have to do this instead:


    if (X < 0) or (X > 9) then ErrorMessage('Please enter a digit');

    Pain in the neck.  Mind you, C's only slightly better - it has a couple of well-known bugs in its precedence.


    As for your foo function: the first one looks like COBOL to me, so don't laugh!  The second is kind of OK, but if you like minimalism, try Perl:


    sub foo { $_*$_; }

    (Although any programmer who puts code like that in a production program should be castrated.)

    I happen to think that PHP's syntax is about the right trade-off for me:


    function foo($x)
    {
      return $x * $x;
    }

    The dollar signs (or dollar/percent/at/asterisk signs in Perl) are a good way to future-proof a language: there's no way a variable name like $class or $throw will ever become a reserved word in version (n+1) of the language.  They also make it easy to see what's a variable and what's not if you don't have smart syntax highlighting.


    What were we talking about again?
  • (cs) in reply to bat
    bat:
    ... and like Vegemite and nasal sex, it's an acquired taste.

    While I can (almost) see someone acquiring a taste for nasal sex, you will never convince me that Vegemite consumption is anything other than a public display of bravado -- Aussies needed something viler than the merely foul Marmite those pommie poofters were eating so they could prove their intrinsic toughness.
  • Rody (unregistered) in reply to Stan Rogers
    Stan Rogers:
    bat:
    ... and like Vegemite and nasal sex, it's an acquired taste.

    While I can (almost) see someone acquiring a taste for nasal sex, you will never convince me that Vegemite consumption is anything other than a public display of bravado -- Aussies needed something viler than the merely foul Marmite those pommie poofters were eating so they could prove their intrinsic toughness.


    Funny, when i read that I thought of nasal sex AND vegemite.  Strange thing to use as a lubricant, I know, but different strokes for different folks.

    And to defend Vegemite, the only thing better than vegemite on crumpet is peanut butter.
  • FreddyF (unregistered) in reply to Rody
    Anonymous:
    Stan Rogers:
    bat:
    ... and like Vegemite and nasal sex, it's an acquired taste.

    While I can (almost) see someone acquiring a taste for nasal sex, you will never convince me that Vegemite consumption is anything other than a public display of bravado -- Aussies needed something viler than the merely foul Marmite those pommie poofters were eating so they could prove their intrinsic toughness.


    Funny, when i read that I thought of nasal sex AND vegemite.  Strange thing to use as a lubricant, I know, but different strokes for different folks.

    And to defend Vegemite, the only thing better than vegemite on crumpet is peanut butter.


    The only real WTF here is this sick sick individual daring to defend Vegimite
  • Taryn (unregistered) in reply to FreddyF
    Anonymous:
    Anonymous:
    Stan Rogers:
    bat:
    ... and like Vegemite and nasal sex, it's an acquired taste.

    While I can (almost) see someone acquiring a taste for nasal sex, you will never convince me that Vegemite consumption is anything other than a public display of bravado -- Aussies needed something viler than the merely foul Marmite those pommie poofters were eating so they could prove their intrinsic toughness.


    Funny, when i read that I thought of nasal sex AND vegemite.  Strange thing to use as a lubricant, I know, but different strokes for different folks.

    And to defend Vegemite, the only thing better than vegemite on crumpet is peanut butter.


    The only real WTF here is this sick sick individual daring to defend Vegimite


    you have to be aware that some Aussies are actually on this list too... :)
    vegemite is the salty stuff you eat (spread very thinly) on toast when you're feeling a bit under the weather - mmm, vitamin B-family and salt :)
  • (cs) in reply to Taryn

    What about vegemite's unpopular cousin, promite?

  • (cs) in reply to gondalez

    Being an Aussie, I just couldn't resist weighing in on this argument :)

    Promite is ok, but just doesn't cut it for me. Same goes for Marmite.

    I seriously really enjoy vegemite. It's fantastic. A couple of years
    ago I went overseas and after about a week was dying for the stuff,
    but couldn't find it anywhere. It's the only thing that I really like
    for breakfast (on toast) - nothing beats it.

    Bravado? Hardly. In Australia, you'll find a jar of vegemite in almost everyone's
    cupboard :)

  • (cs)

    Though it's not my code I so recognise these begin/end macro's [:D]

    In my early days as a hobby programmer I used turbo pascal and one day had a go at C. I really hated using the brackets so I made the exact same macro's. Soo funny [:D]

  • Anonymous (unregistered)

    Since no one has said something about the third one, which is in ColdFusion, I'll put something up.

    The real WTF is of course

    if A
      do B
    else
      do B
    

    but you can also see that the author is not very experienced with CF. Within CF-tags, you do not need the pound-sign for variable output. E.g. you can use

    <cfif UseGroups EQ "1">

    instead of

    <cfif #UseGroups# EQ "1">.

    Furthermore CF doesn't really distinguish between types, so

    <cfif UseGroups EQ 1>

    would have been just fine and more readable. Similar for

    <cfset LastRound=CurrentRound>

    Next, another good thing is that if you use comments with three dashes (so <!--- ... ---> instead of <!-- ... -->) CF will hide this and not include it in the output source, which is generally what you would want, as it is a comment for programming purposes, not for information to the user.

    Finally, the following would have been more concise:

    <tr><td>
      <cfif #UseGroups# EQ "1">
        There are no fixtured games to display
      <cfelse>
        There are no fixtured games to display
      </cfif>
    </tr></td>
    

  • (cs)

    First I was gonna mention that this is why I never read WTF early in the day, you gotta really build up to it, then I was gonna beg for all the bad code to stop.

    Then I was gonna beg for the language wars to stop (besides, everyone knows that handed coded 6502 was the pinacle of development)

    then I was gonna beg for the whole nasal sex/vegamite thread to stop.

    and then someone suggested using the vegamite as a lubricant, and suddenly I found my self wondering what the contraceptive value might be.

    Now I'm just begggin for my spining moral compass (and rolling stomach) TO STOP.

    With my luck, however, it would stop between C++ baptist and object-cobal atheist (can you think of a better reason to believe there is no god?) and I would have have endless aguments with myself ending in a nuclear holocost.

  • (cs)
    Alex Papadimoulis:

    And finally, here's another bit from Tristan Harmer. His colleague, aparantly, didn't quite understand the "repeating" nature of a repeater ...

    Private Sub LoadAllAreaList()

    Dim dsDataSet As New DataSet()
    Dim drDataRow As DataRow

    'Create dummy dataset to allow us to use the repeater
    dsDataSet.Tables.Add()
    drDataRow = dsDataSet.Tables(0).NewRow()
    dsDataSet.Tables(0).Rows.Add(drDataRow)

    'Bind datareader to repeater
    rptAll.DataSource() = dsDataSet
    rptAll.DataBind()

    End Sub



    I only know a little VB - could someone explain in more detail why this is a WTF, and what a proper re-implementation would look like?

  • (cs) in reply to emurphy
    emurphy:
    Alex Papadimoulis:

    And finally, here's another bit from Tristan Harmer. His colleague, aparantly, didn't quite understand the "repeating" nature of a repeater ...

    Private Sub LoadAllAreaList()

    Dim dsDataSet As New DataSet()
    Dim drDataRow As DataRow

    'Create dummy dataset to allow us to use the repeater
    dsDataSet.Tables.Add()
    drDataRow = dsDataSet.Tables(0).NewRow()
    dsDataSet.Tables(0).Rows.Add(drDataRow)

    'Bind datareader to repeater
    rptAll.DataSource() = dsDataSet
    rptAll.DataBind()

    End Sub



    I only know a little VB - could someone explain in more detail why this is a WTF, and what a proper re-implementation would look like?

    What the code does:

    • Create a dataset with a single datatable
    • Add a single row to the datatable
    • Bind the dataset to a repeater control

    One WTF is using the repeater to display a single record. A repeater is for showing multiple records (I think thats why its name is REPEATer). Another WTF is that there is no data in the single row of the datatable!

    The proper way would be to not use the repeater at all :)

  • (cs) in reply to gondalez

    The main problem I have with brackets for marking code blocks is they all look the same.

    you get to the bottom of some code and you find:

        a++;
    }

    Oh bugger, what was that } for again? At least in something like VB or similar you can tell that sort of thing at a glance.

        a++
    end for

        a++
    end if

        a++
    loop until a>b

    etc.

    You can keep your eyes on the area of code your working on instead of having to refer back up to the top of the block (maybe even off the page) to remind yourself what you were doing with that }.

    Of course all it takes is a few levels of nesting and it can look really confusing. I can get along fine in C style syntax, I just happen to think that they sacrificed readability in favour of cool looking squiggles.

  • (cs) in reply to RayS

    Fair comment about the squiggles vs end if/while/for/etc, but you ain't seen nuthin' until you've gotten to the end of a bit of LISP and seen:

    ))))))))))))))))

    Just about forces you to factor your code into small, simple chunks, which is a Good Thing.
  • (cs)

    Thanks for the prop, man. I'm glad to see that the site is still active and still apparently getting a shload of traffic! Happy blogoversary!

  • shez (unregistered) in reply to Anon
    new function foo returns type integer takes arguments x with type integer
    begin the function's block
      return the value x multiplied by x

    <font size="2">You have a syntax error here.  It should be:

    return the value x multiplied by the value x
    </font>
    :)

    end the function's block

  • (cs) in reply to Stan Rogers

    Stan Rogers:


    It's unlikely that basic arithmetic operations would be replaced by text descriptions of the operation in any language that natively supports arithmetic, so I'll let the illogical line slide.

    Doesn't Cobol have some hideously verbose syntax along these lines:

    add x to y giving z

     

  • (cs) in reply to Miszou

    COBOL? This is supposed to be a programming forum, not a comparative literature symposium. (I work with some of the remaining novelists, and can't resist the zing.)

  • (cs) in reply to shez
    Anonymous:

      return the value x multiplied by x
    <font size="2">return the value x multiplied by the value x
    </font>


    or even

    return the value (the value x multiplied by the value x)
    :) :)
  • Alan W. Balkany (unregistered) in reply to RayS

    The main problem I have with brackets for marking code blocks is they all look the same.

    you get to the bottom of some code and you find:

        a++;
    }

    Oh bugger, what was that } for again?

    ======================

    The standard way to deal with that is with a comment telling what the bracket is matched to, e.g.

     

          }      // End if.

       }      // End class.

    }      // End namespace.

     

    If this doesn't help, your method is too long; break it up into subroutines.

  • (cs) in reply to Alan W. Balkany
    Anonymous:

    The main problem I have with brackets for marking code blocks is they all look the same.

    you get to the bottom of some code and you find:

        a++;
    }

    Oh bugger, what was that } for again?

    ======================

    The standard way to deal with that is with a comment telling what the bracket is matched to, e.g.

     

          }      // End if.

       }      // End class.

    }      // End namespace.

     

    If this doesn't help, your method is too long; break it up into subroutines.



    Comments should NEVER tell you about the code. They should tell you what the code is doing. Besides, that's relying on (a) everyone involved with the code following the standard, (b) anyone changing the code to remember to update after any changes, (c) manually doing more typing. And let's face it, they're all bad news.

    Besides, if you have to hack basic code readability with comments, don't you think there's something inherently wrong with the syntax?

    "I know paper's a bad material for building a house, but if you treat it with A, strengthen it with B, waterproof if with C, fireproof it with D, and use special process E when making the house, it works."
    "Yeah, or I could just use bricks."

  • PeteM (unregistered) in reply to gondalez
    gondalez:

    What the code does:

    • Create a dataset with a single datatable
    • Add a single row to the datatable
    • Bind the dataset to a repeater control

    One WTF is using the repeater to display a single record. A repeater is for showing multiple records (I think thats why its name is REPEATer). Another WTF is that there is no data in the single row of the datatable!

    You don't know the circumstances of this call to say that it is a WTF to display an empty single row in a repeater.

    It could be that this is only called when another routine had determined that the normal data view was found to be empty.

    It could also be that the repeater was going to be used to show data that was going to be built by the app, the first entry was not there yet so he displays a blank record initially then replaces it with a real data when available. This means the repeater will always be there and you don't keep getting phone calls from users saying "XYZ is not there! Oh, it's just appeared"

    Out of context you can not say for certain this is a WTF

  • (cs) in reply to RayS

    "Besides, if you have to hack basic code readability with comments, don't you think there's something inherently wrong with the syntax?"

    Actually, if the blocks are so long that you're having a problem, then the blocks are too long.

    I'd heard a lot of reasons "why VB gives programmers bad habits", but you've introduced me to a new one - that it leads to multi-page blocks. Thanks you. I think.

  • (cs) in reply to PeteM
    Anonymous:
    gondalez:

    What the code does:

    • Create a dataset with a single datatable
    • Add a single row to the datatable
    • Bind the dataset to a repeater control

    One WTF is using the repeater to display a single record. A repeater is for showing multiple records (I think thats why its name is REPEATer). Another WTF is that there is no data in the single row of the datatable!

    You don't know the circumstances of this call to say that it is a WTF to display an empty single row in a repeater.

    It could be that this is only called when another routine had determined that the normal data view was found to be empty.

    It could also be that the repeater was going to be used to show data that was going to be built by the app, the first entry was not there yet so he displays a blank record initially then replaces it with a real data when available. This means the repeater will always be there and you don't keep getting phone calls from users saying "XYZ is not there! Oh, it's just appeared"

    Out of context you can not say for certain this is a WTF

    I suppose you're right! Except that I'm the one that submitted the code :)

    The repeater was used once and once only to display a couple of maps.  The url of the map images were set within then ItemDatabound event of the repeater.  Why it was done that way I don't know, although my guess would be a blind cut & paste (there were a few other repeaters used to display multiple maps).

    Getting rid of the repeater made things a lot clearer.

  • endothermal (unregistered) in reply to RayS

    RayS:
    The main problem I have with brackets for marking code blocks is they all look the same.

    you get to the bottom of some code and you find:

        a++;
    }

    Oh bugger, what was that } for again? At least in something like VB or similar you can tell that sort of thing at a glance.

        a++
    end for

        a++
    end if

        a++
    loop until a>b

    etc.

    You can keep your eyes on the area of code your working on instead of having to refer back up to the top of the block (maybe even off the page) to remind yourself what you were doing with that }.

    Of course all it takes is a few levels of nesting and it can look really confusing. I can get along fine in C style syntax, I just happen to think that they sacrificed readability in favour of cool looking squiggles.

    that's why your choice of IDE is very important.  In visual studio .net, if you have a } sitting somewhere move your cursor next to it and hit ctrl{or ctrl } and it will jump you to the opening or closing of the block and highlights the opening and closing { } so you can which are paired.  It also does this for the regular brackets.  I'm positive other IDEs do this as well. 

     

  • (cs) in reply to RayS

    RayS:

    Oh bugger, what was that } for again? At least in something like VB or similar you can tell that sort of thing at a glance.

    ...


    You can keep your eyes on the area of code your working on instead of having to refer back up to the top of the block (maybe even off the page) to remind yourself what you were doing with that }.

    Of course all it takes is a few levels of nesting and it can look really confusing. I can get along fine in C style syntax, I just happen to think that they sacrificed readability in favour of cool looking squiggles.

    As Bellingham already wrote, if you can't see the entire block in a single page (approx. 50 lines), you're blocks are probably too long.  Basically you are advocating a certain syntax because it helps when writing bad code.  If you have more than two or threee layers of nesting, it's time to create a new method/function/subroutine.  Lastly, indentation is a great thing.

    All of that aside, I persoanlly prefer the curly braces over 'end if' or 'end while'.  It's not because they are 'cool', it's because 'end if' and 'end while' look like code, not control structures.  I've worked with both and the 'end if' style is much more jumbled to my eyes.  I can look at c style code and immediately see the structure of the code without reading every line.

  • charlie collins (unregistered) in reply to Bellinghman

    Exactly.  If you need the comments to "navigate" the structure then the "blocks" are too damn long.  Those arent bad comments per se (the little // end this loop) but they are uneccessary if your code is well designed in that methods are fairly atomic and have sane logic

    • on their own.

    Write Sweet-Smelling Comments
  • (cs) in reply to dubwai
    dubwai:

    RayS:

    Oh bugger, what was that } for again? At least in something like VB or similar you can tell that sort of thing at a glance.

    ...


    You can keep your eyes on the area of code your working on instead of having to refer back up to the top of the block (maybe even off the page) to remind yourself what you were doing with that }.

    Of course all it takes is a few levels of nesting and it can look really confusing. I can get along fine in C style syntax, I just happen to think that they sacrificed readability in favour of cool looking squiggles.

    As Bellingham already wrote, if you can't see the entire block in a single page (approx. 50 lines), you're blocks are probably too long.  Basically you are advocating a certain syntax because it helps when writing bad code.  If you have more than two or threee layers of nesting, it's time to create a new method/function/subroutine.  Lastly, indentation is a great thing.

    All of that aside, I persoanlly prefer the curly braces over 'end if' or 'end while'.  It's not because they are 'cool', it's because 'end if' and 'end while' look like code, not control structures.  I've worked with both and the 'end if' style is much more jumbled to my eyes.  I can look at c style code and immediately see the structure of the code without reading every line.


    Surely that's more a function of the indenting than the }s themselves?

    But without the issue of overly large multi-page code blocks, isn't looking one line up to get a reminder of where you are better than looking 20-30 lines up? One allows you to essentially not moves your eyes, the other requires you to move your focus elsewhere. Squiggle syntax + comments does get around this, but it's a bug-prone hack.

    Regarding distinguishing between code and control structures, I personally have no problem with that. That aspect of it is more than likely a case of what you're most used to than either method being inherently better.
  • Jay Bazuzi (unregistered)

    Happy blogiversary, DailyWTF!

     

  • tharpa (unregistered) in reply to Stan Rogers
    While I can (almost) see someone acquiring a taste for nasal sex, you will never convince me that Vegemite consumption is anything other than a public display of bravado -- Aussies needed something viler than the merely foul Marmite those pommie poofters were eating so they could prove their intrinsic toughness.

    I am rather fond of Vegemite. Though as far as the other thing goes, I have yet to find a willing elephant.

Leave a comment on “Miscellaneous WTFery”

Log In or post as a guest

Replying to comment #:

« Return to Article