The code beautifier WTF



  • My co-workers submitted their PL SQL packages that they had coded, to my boss for code review.
    Pat comes the reply -
    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".
    Guess what happens now:
    They all go into a frenzy and start jabbing feverishly away at their keyboards like monkeys hoping to turn in the newly beautified code before going home.
    After a 3-4 hours of hectic activity they give up. No one seems to like banging the tab, caps and enter keys and retype their code just to have some girly looking code for the boss.

    Apparently, they didnt know how to use a beautifier.
    This, after being trained in PLSQL for 6 months.


    PS: The packages were 1k-3k lines long atmost.



  • @byte_lancer said:

    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".

    Code from some of my coworkers looks like that: Oracle keywords as well as the names of database objects (tables, columns, etc.) are all uppercase. In other words, almost everything is uppercase, except a few variables. I hate it when it looks like this.



  • 20+ years ago, before I encountered my first code beautifier, I used to brute force the 'beautification process' by doing the following:

    cat the source file into a stream, splitting it into one word per line
    pipe through sed to strip out numbers and assorted punctuation
    pipe through uniq
    pipe through a canned script to strip out the reserved words of the language
    pipe through a canned script to split into 2 files: one with DB reserved words, one without
    cat each into a sed script to generate a shell file that runs sed on each word to [un]cap it
    then run the whole thing on the source file.

    Then I had a simple program that indented 3 spaces for each opened block - just ran the code through it and voila: formatted, [un]capitalized reserved/DB words, etc. It all ran as a single shell script, so it was easy to use. Of course, it was fully documented as it wasn't at all obvious how it did what it did, as it was one long chain of piped commands... Crude by today's standards, but in its day, it beat doing it by hand.


  • @snoofle said:

    20+ years ago, before I encountered my first code beautifier, I used to brute force the 'beautification process' by doing the following:

    cat the source file into a stream, splitting it into one word per line
    pipe through sed to strip out numbers and assorted punctuation
    pipe through uniq
    pipe through a canned script to strip out the reserved words of the language
    pipe through a canned script to split into 2 files: one with DB reserved words, one without
    cat each into a sed script to generate a shell file that runs sed on each word to [un]cap it
    then run the whole thing on the source file.

    Then I had a simple program that indented 3 spaces for each opened block - just ran the code through it and voila: formatted, [un]capitalized reserved/DB words, etc. It all ran as a single shell script, so it was easy to use. Of course, it was fully documented as it wasn't at all obvious how it did what it did, as it was one long chain of piped commands... Crude by today's standards, but in its day, it beat doing it by hand.


    A lazier developer would have invented Perl to solve this problem for them.


  • The WTF is that PLSQL developer has a built in beautifier and none of these folks thought of using it.



  • @byte_lancer said:

    The WTF is that PLSQL developer has a built in beautifier and none of these folks thought of using it.

    Maybe they didn't want to spend $240US each for licenses? I would not use PL/SQL Developer if it were free - it is extremely buggy and unstable. For example, its debugger works by wrapping your code in its own generated package, which, the way Oracle works, turns you into a serial process. In other words, you lock every other user out of making changes.

    The other IDEs are not much better, but expect good things to come from the free ones, such as SQL Developer and Eclipse.

    I don't like features like beautifiers in an IDE anyhow - that usually means you can't tinker with it. Most hardcore developers I've known do that sort of thing in text editor macros or scripting languages. That way you can alter it as the style changes.



  • @RyuO said:

    @byte_lancer said:
    The WTF is that PLSQL developer has a built in beautifier and none of these folks thought of using it.

    Maybe they didn't want to spend $240US each for licenses?
    .....
    I don't like features like beautifiers in an IDE anyhow - that usually means you can't tinker with it. Most hardcore developers I've known do that sort of thing in text editor macros or scripting languages. That way you can alter it as the style changes.


    Err, we dont need to spend that 240$. All dev machines here come pre-installed with PLSQL dev. We're somehow related to the shark that created this 'IDE'.

    I share the same opinion w.r.t beautifiers - I always want customisability. Eclipse comes close to it so no more Perl code (thankfully).



  • I would have laughed the first hour, then TOLD them how to use it, rather than watching all my coworkers waste that much time.



  • @jesirose said:

    I would have laughed the first hour, then TOLD them how to use it, rather than watching all my coworkers waste that much time.


    A dangerous approach. They might, defending the already invested time, insist on a braindead formating rule that cannot be done configured in the tool.



  • @byte_lancer said:

    My co-workers submitted their PL SQL packages that they had coded, to my boss for code review.
    Pat comes the reply -
    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".
    Guess what happens now:
    They all go into a frenzy and start jabbing feverishly away at their keyboards like monkeys hoping to turn in the newly beautified code before going home.
    After a 3-4 hours of hectic activity they give up. No one seems to like banging the tab, caps and enter keys and retype their code just to have some girly looking code for the boss.

    Apparently, they didnt know how to use a beautifier.
    This, after being trained in PLSQL for 6 months.


    PS: The packages were 1k-3k lines long atmost.

    Wow, that's just brutal.  Can you imagine how many bugs just appeared in that code?



  • @byte_lancer said:

    @RyuO said:
    @byte_lancer said:
    The WTF is that PLSQL developer has a built in beautifier and none of these folks thought of using it.

    Maybe they didn't want to spend $240US each for licenses?
    .....
    I don't like features like beautifiers in an IDE anyhow - that usually means you can't tinker with it. Most hardcore developers I've known do that sort of thing in text editor macros or scripting languages. That way you can alter it as the style changes.


    Err, we dont need to spend that 240$. All dev machines here come pre-installed with PLSQL dev. We're somehow related to the shark that created this 'IDE'.

    I share the same opinion w.r.t beautifiers - I always want customisability. Eclipse comes close to it so no more Perl code (thankfully).

    I would like to see something that wrote source code out in a consistent format, but edited and viewed the files formatted to the user's taste.  That way no one would be clobbering anyone else for using spaces instead of tabs, making the lines too long, etc.



  • @ammoQ said:

    @jesirose said:
    I would have laughed the first hour, then TOLD them how to use it, rather than watching all my coworkers waste that much time.


    A dangerous approach. They might, defending the already invested time, insist on a braindead formating rule that cannot be done configured in the tool.

    Bingo. That's what happened. They changed tacks only when they were tutored to use the beautifier.

    --The problem with idiots is that they think everyone else is a worser idiot.



  • @Oscar L said:

    Wow, that's just brutal.  Can you imagine how many bugs just appeared in that code?


    Bugs? Serpents is more like the word.



  • @byte_lancer said:


    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".


    At least in mysql, there's a valid reason to do this: The query cache is case sensitive.  That is, if application A runs 'SELECT * FROM users;',  and app B runs 'SELECT * FROM users;' within a certain time limit, the results for the second query will come from the cache.

    However, if app A runs 'SELECT * FROM users;' and B runs 'select * from users;', B's query will be considered to be a completely different query, and any cached result will be ignored.



  • @merreborn said:

    @byte_lancer said:

    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".


    At least in mysql, there's a valid reason to do this: The query cache is case sensitive.  That is, if application A runs 'SELECT * FROM users;',  and app B runs 'SELECT * FROM users;' within a certain time limit, the results for the second query will come from the cache.

    However, if app A runs 'SELECT * FROM users;' and B runs 'select * from users;', B's query will be considered to be a completely different query, and any cached result will be ignored.

    Oracle has the same feature: the SQL area is sensitive to both case and whitespace in determining DML reusability. That does not explain why the 3GL part of the language follows the same convention - aesthetics, maybe?

    The keywords-uppercase convention has been dominant in the Oracle world for about 10 years. No idea why, exactly - it was only one of several conventions in the Algol family. I don't even think it was common until Modula-2 and Ada. No matter - a common standard is second only to readability in stylistic criteria.



  • @RyuO said:

    @merreborn said:
    @byte_lancer said:

    "Put all Oracle keywords in uppercase, variables in lowercase and dont forget the indentation".


    At least in mysql, there's a valid reason to do this: The query cache is case sensitive.  That is, if application A runs 'SELECT * FROM users;',  and app B runs 'SELECT * FROM users;' within a certain time limit, the results for the second query will come from the cache.

    However, if app A runs 'SELECT * FROM users;' and B runs 'select * from users;', B's query will be considered to be a completely different query, and any cached result will be ignored.

    Oracle has the same feature: the SQL area is sensitive to both case and whitespace in determining DML reusability. That does not explain why the 3GL part of the language follows the same convention - aesthetics, maybe?

    The keywords-uppercase convention has been dominant in the Oracle world for about 10 years. No idea why, exactly - it was only one of several conventions in the Algol family. I don't even think it was common until Modula-2 and Ada. No matter - a common standard is second only to readability in stylistic criteria.

    Probably just came from the time before color displays.  These days I rely entirely on syntax highlighting, since it hurts my eyes and wrists to constantly switch between cases.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.