Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wouldn't syntax highlighting help with most of the issues you've outlined?


If I've got my developer hat on, yeah, sort of. I still find the case differences more pronounced without necessarily forcing me into a more in-my-face code formatting theme. Also, for all the reason A code format is important, the fact that I have 20 years experience with up-to-now SQL norms mean that I'm trained to look for certain things and can, almost without thinking, focus in on those with the help of historical formatting. Arbitrary changes to that history mean that now I have to discard that muscle memory and learn new ways of looking at things... I'm not sure the gain of a few less caps locks keystrokes merits forcing that learning curve. Sure the kids won't care about that because there's nothing to lose, but some of us old timers lose the benefit of our experience.

But developers with good tooling to deal with more static views of the code aren't the only readers of SQL, and perhaps not the most common.

With my DBA hat on, trying to figure out what's going on reading through logs and such, I don't always have that kind of tooling available. In this context the casing can help as well.... and this may form some of my bias; my first professional experiences on the application side of the world were in very much DBA roles dealing with other people's applications running on my servers. Insofar as access tools preserve developer formatting, having good "color-blind" formats made reading complex queries easier.


Yeah indeed -- though I'd prefer to write all lowercase for the sake of ease, I too stick to the 'uppercasing' norms mainly to help with ease of readability -- especially in shell-only environments where syntax highlighting isn't available [e.g., using psql]


Syntax highlighting is a huge boon working with SQL, but unfortunately you often find you are working with SQL embedded as a string in some other programming language.

I wonder if programming languages should have a way of specifying that a string constant contains embedded code or a template, so text editors can display it accordingly.

I deal with a lot of SQL embedded in code, and prefer uppercase keywords as it seems to help me visually parse the overall file.


PyCharm (and likely other editors by Jetbrains) supports embedded programming languages! However, language level support so that this could be automatically done by all editors would be great.


a lot of programming languages do have a way of specifying that a string constant contains embedded code or a template. Sublime Text for example will look for PHP heredocs with an identifier of XML, HTML, SQL etc. to know what to lex/highlight the string as. Or it will check whether the string starts with an uppercase "SELECT", as the chances are it's gonna be SQL. Code fences in GitHub Formatted Markdown are also a good example of this hinting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: