• @Nolegjoe
    link
    738 months ago

    I’m a sql developer, and I am completely the opposite to you. I will find it incredibly difficult to read when everything is in caps

    • @[email protected]
      link
      fedilink
      258 months ago

      Same, I prefer lower case. Every other language has keywords in lower case, why do you need to shout when writing sql?

      • @[email protected]
        link
        fedilink
        21
        edit-2
        8 months ago

        I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times

        • @[email protected]
          link
          fedilink
          12
          edit-2
          8 months ago

          Partially, yes. I personally use an IDE with excellent syntax highlighting and those have been around for at least two decades. You are, however, often transplanting your SQL between a variety of environments and in some of those syntax highlighting is unavailable (for me at least) - the all caps does help in those rare situations.

          More importantly though it helps clearly differentiate between those control keywords (which are universal) and data labels (which are specific to your business domain). If I’m consulting on a complex system that I only partially understand it’s extremely helpful to be able to quickly identify data labels that I’m unfamiliar with to research.

        • Bonehead
          link
          fedilink
          8
          edit-2
          8 months ago

          it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times

          You say that as if AS400 systems with only console access don’t exist anymore.

          • @[email protected]
            link
            fedilink
            28 months ago

            Well then use all-caps keywords whenever working on those systems, I don’t care. But an edge case like that shouldn’t dictate the default for everyone else who doesn’t have to work on that, that’s all I’m saying.

            • Bonehead
              link
              fedilink
              48 months ago

              There are several cases where you’ll be limited to console only, or log files, or many many other situations. Good coding practices just makes life easier all around.

        • @[email protected]
          link
          fedilink
          8
          edit-2
          8 months ago

          Please tell me what IDE you’re using that’s capable of highlighting SQL syntax that’s embedded inside another language source file

          Also please fucking stop with the “it’s current year stop x.” The year is not an argument.

          • @[email protected]
            link
            fedilink
            48 months ago

            JetBrains IDEs - IntelliJ, WebStorm, PyCharm, GoLand, etc., all support highlighting SQL embedded in another source file or even inside markup files like YAML. Does your IDE not support this?

          • @[email protected]
            link
            fedilink
            28 months ago

            As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.

            • @[email protected]
              link
              fedilink
              2
              edit-2
              8 months ago

              Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.

              • @[email protected]
                link
                fedilink
                28 months ago

                I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.

                • @[email protected]
                  link
                  fedilink
                  1
                  edit-2
                  8 months ago

                  I’m currently using SQLx which you write raw queries in and it validates them against a currently-running db, using the description of the tables to build the typing for the return type instead of relying on the user. It makes it pretty hard to write anything that supports injection

                  • @[email protected]
                    link
                    fedilink
                    28 months ago

                    Oh, that sounds really cool! At what time does this validation happen? While you code, or later at build time?

        • @jaybone
          link
          38 months ago

          Also some people are color blind.

          Also you might need to ssh in somewhere and vi some code or tail a log file where you don’t have color support.

          • @[email protected]
            link
            fedilink
            18 months ago

            My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.

            Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.

        • @[email protected]
          link
          fedilink
          38 months ago

          Yea - you want the structure in a recognizable form so that you can quickly confirm code patterns for comprehension.

    • @[email protected]
      link
      fedilink
      18
      edit-2
      8 months ago

      Sorry, to clarify, not everything is in all caps. I’ll append my prefered syntax below

      WITH foo AS (
          SELECT id, baz.binid
          FROM
                  bar
              JOIN baz
                  ON bar.id = baz.barid
      )
      SELECT bin.name, bin.id AS binid
      FROM
              foo
          JOIN bin
              foo.binid = bin.id
      

      The above is some dirt simple SQL, when you get into report construction things get very complicated and it pays off to make sure the simple stuff is expressive.

      • @NedDasty
        link
        148 months ago

        You indent your JOIN? Why on earth? It lives in the same context as the SELECT.

        • @[email protected]
          link
          fedilink
          98 months ago

          I’ve seen both approaches and I think they’re both quite reasonable. An indented join is my preference since it makes sub queries more logically indented… but our coding standards allow either approach. We’ve even got a few people that like

          FROM foo
          JOIN bar ON foo.id = bar.fooid
          JOIN baz ON bar.id = baz.barid
          
        • @callcc
          link
          68 months ago

          Actually not. It’s part of the FROM

      • @Cold_Brew_Enema
        link
        18 months ago

        Um you forgot the semicolon before with assuming there isn’t one in the previous statement. Syntax error. Code review failed

        • @[email protected]
          link
          fedilink
          58 months ago

          There’s no way we’re running in multi statement mode… I like my prepared queries, thank you very much.

      • @Siethron
        link
        1
        edit-2
        8 months ago

        deleted by creator

    • idunnololz
      link
      1
      edit-2
      8 months ago

      I believe this has been proven. It’s because capital letters all have the same shape whereas lower case letters do not. So your brain can take shortcuts to reading lower case but cannot with upper case.

      Also most if not all editors will highlight SQL keywords so it’s probably not too hard to discern SQL commands and everything else in modern day.