Whether we should be CAP COPs

Question

A certain user has suggested a boatload of edits recently. The changes have been either largely or completely revolving around the upper-casing of Transact-SQL keywords. For example, a post that looked like this:

select *
from tablename
where columnName = 'foo'

Would be edited to this:

SELECT *
FROM tablename
WHERE columnName = 'foo'

For some, this becomes more readable. I get that; I'm in that group that prefers upper-case keywords. However, that is not everyone. Plus some other issues were missed here (missing schema prefix, missing trailing semi-colon, the use of SELECT *) that could definitely be a better target for improvements or at least mentioned as potential bad habits.

Some arguments against this behavior of editing someone else's code merely to transform case of keywords:

1. This becomes less readable for some (just not for you).
2. This is no longer the code the OP wrote, and is no longer in the format of the OP's preference (regardless of your preference).
3. Keywords are not case sensitive in Transact-SQL. Just because you like SELECT does not necessarily mean that is the standard we as a group should be encouraging, never mind enforcing.

But I'm putting this out to the community. Should we encourage users to post edits that only (or not much more than) "correct" the casing of T-SQL keywords? If we should, should we not then also enforce this standard and perform the same types of edits ourselves? If the community agrees that upper-casing T-SQL keywords is "correct" then we shouldn't ever see a lower-case keyword on the site, right?

Answer 1

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 the SELECT list, use of LEFT JOIN vs. LEFT OUTER JOIN, use of AS 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 to your preferences), is likely to lead to arguments and edit wars. All we need are two strong-headed people - one who likes select, and one who likes SELECT, 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.

Answer 2

My answer is a firm NO. 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 my subjective 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.

Answer 3

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.