[jolmg]

> As an aside, is there some reason that using the same identifier with different cases is desirable?

It's not like that. The thing is that having case insensitive identifiers incentivices people to be inconsistent with their casing "because it doesn't matter" as one coworker that works in a case insensitive language said to me. "Whoops, I wrote 'vALUE'. Well, it doesn't matter; it works. :)" Thank god I don't have to touch that codebase. I do wonder on average how many different variations of casing is used for each variable and keyword.

[beagle3]

... It's like using curly braces to delimit scope incentivizes people to be inconsistent with indentation because "it doesn't matter".

Yes, there are always people who would do stupid stuff.

But we have decades of experience with Pascal, SQL, VB, VB.Net, Excel and variety of other languages. Decades. They each have their problems, but in wide practice, case [in]sensitivity is not one of them.

[jolmg]

Yet inconsistent indentation is a problem in wide practice. It doesn't take long to find popular open source projects that mix tabs and spaces in their indentation.

Of course, many people are going to be consistent with their casing even when using a case insensitive language, but it's nice to know that particular forms of bad style are never going to be an issue because particular rules of good style are enforced by the language.

[beagle3]

Inconsistent indentation is NOT a problem in practice.

inconsistent tab/space use is a problem in practice (not a "wide" one in my experience, but not negligible), but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too.

I've never heard of someone saying "I don't care about mixing spaces and tabs because it's the curly braces that matter", and I've never heard of someone who edits a file with inconsistent on-screen indentation and doesn't care.

[jolmg]

> Inconsistent indentation is NOT a problem in practice. inconsistent tab/space use is a problem in practice

Alright, I was talking about the latter, which causes the former when you're not evaluating file modelines.

> not a "wide" one in my experience

I have a ~/build directory that contains source files of 207 projects whose source I've downloaded over the years for various reasons. Of those 207, if I look for mixes of tabs and spaces in indentations using:

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s*( \t|\t )' $p/^.git | head -1
  done | wc -l

I get 144. You may consider the pattern `\t ` ok though because some people think it's cool to use tabs for indentation and spaces for alignment, but if I exclude those:

  for p in ~/build/{pkg,repo}/*; do
    grep -IPlr '^\s* \t' $p/^.git | head -1      
  done | wc -l

I still get 110. Now, those are just the ones that have a space and then a tab in one indentation. How about those that use a space as the first character in one indentation and then a tab as an adjacent line's first character in its indentation?

  for p in ~/build/{pkg,repo}/*; do
    ag -lr '^ .*\n\t|^\t.*\n |^\s* \t' $p/^.git | head -1 
  done | wc -l                       

That's 142.

If I run that last one only against pkg/, which contains mostly official package sources of my distro, then I get 69 matches out of 89 packages.

Note these are not file counts, but project counts with at least one such file.

You may view this as using a small sample size, but at least, the practice is pretty wide in my experience.

[jolmg]

I forgot to mention:

> but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too.

This isn't going to work when you're looking at a diff/patch, emailing an excerpt or otherwise looking at the code outside of a particular editor.