Probably obvious from the tone of my question, but even though I prefer upper-case keywords, I don't feel it is our job as editors or reviewers to encourage and even reward behavior that is merely the enforcing of one's preferences onto others.

I understand that often the intent is to improve the post. But on its own I don't think this should be a valid edit that gets approved. Just like other formatting issues that are not correct or incorrect, but preferences - for example, placement of commas in theSELECT list, use ofLEFT JOIN vs.LEFT OUTER JOIN, use ofAS for aliases, etc.

Even in combination with other valid formatting edits (such as removal of horizontal scrollbars, which hide content from readers), I think changing case is questionable at best, and should not be encouraged. It doesn't change the meaning or the validity of the code, and whether it affects readability is in the eye of the editor, not necessarily the audience.

If we don't decide as a group that upper-casing T-SQL keywords is "correct" (and I don't know how we could), then changing someone else's post to adhere to your preferences is, by definition, incorrect. IMHO.

In addition, encouraging this type of behavior (where it's okay to edit someone else's post to conform toyour preferences), is likely to lead to arguments and edit wars. All we need are two strong-headed people - one who likesselect, and one who likesSELECT, with equal stubbornness and tenacity, and a desire to enforce their preferences onto every post they see. Extreme example? Perhaps. But I don't want to test that. YMMV.

My answer is a firmNO. There are only a handful of reasons I can think of that would make it ok to edit someone else's code in either a question or answer:

1. There's a typo that would prevent the code from working as is.
2. Reformatting to lay out the code so that it's visible. No nitpicking, just taking bunched up 1-2 lines of code and spreading it out into something readable on the page.

If there's a logic problem in the code, then either answer the question (if it's asking for help fixing it) or leave a comment as to what the issue is.

The inherent problem is that what I like code to look like is completely different from what YOU like code to look like. I shouldn't be enforcing mysubjective standards onto your code, just like you shouldn't be enforcing your subjective standards onto me.

If someone's having a hard time reading someone's code because of its formatting, then they're more than welcome to copy that code and run SQL Prompt or any other code formatting program they have. I've done that several times in the past.

Also, edits on the SE network should be something substantial that makes the post read easier or easier to understand. Such edits as this are subjective at best and don't help anyone except maybe the person proposing the edit.

• 2
  Even correcting typos (point 1) can affect the context, depending on the question, of course.

  Michael Green

  – Michael Green

  2015-07-09 23:07:38 +00:00

  CommentedJul 9, 2015 at 23:07

I don't think such upper-casing editing is a good idea, because it might discourage people from some cultures. AFAIK, some languages do not have the concept of uppercase/lowercase at all. People from such cultures might not value upper-casing the way we do. They may use upper and lower cases interchangeably, and IMO they should not be discouraged from participating by edits that in their opinion improve nothing.

Let us concentrate on technical content rather than programming style.

I have been working for several years on a team where every person comes from a different country and is a native speaker of a different language. We use a rather minimalistic programming style:

1. No wide lines, because we may have to work from home, and laptop's screen is not as wide as two 30' monitors.
2. No typos, because otherwise search fails to find.
3. No articles, no SaveACurstomer or SaveTheCustomer, only SaveCustomer - again because it is easier to search when there is only one variant.
4. No aliases - if we call an action Save in one place, like SaveOrder, do not call same action against other table PersistCustomer or UpsertCustomer. Same reason as before.

This is it. All rules are there for a strong reason, and there is no potential for controversy.

This site is also an international community, so I would suggest a minimalistic approach to programming style.

• discussion
• edits
• sql-server