Allow spaces in Identifier to write unit tests with readable names

[comfyneet]

I suggest C# should allow spaces in identifier names, to make test names more readable, and easier to interop with F# libraries.

When writing test cases, many people often use self-explaining method names. But long PascalCase names are hard to read (e.g. When2IsAddedTo2Expect4()), many tend to work around this issue by using underscores (e.g. When_2_Is_Added_To_2_Expect_4()), inappropriately they don't follow .NET naming conventions. I suggest we should add single-backtick marks `identifier` syntax, or alternatively F# double-backtick marks ``identifier`` syntax, to have a clearer, straightforward names.

Backtick definition copied from F# spec: "Any sequence of characters that is enclosed in double-backtick marks (`` ``), excluding newlines, tab, and backtick themselves, is treated as an identifier". For example:

[TestFixture]
class MyUnitTests
{ 
    [Test]
    void When2IsAddedTo2Expect4()
    {
        Assert.AreEqual(4, 2 + 2);
    }

    [Test]
    void ``When 2 is added to 2 expect 4``()
    {
        Assert.AreEqual(4, 2 + 2);
    }
}

The backtick syntax makes the test results much easier to read. Here is the output of the test with a standard class name:

MyUnitTests.When2IsAddedTo2Expect4
Result: Success

vs. the output using the more friendly name:

MyUnitTests.When 2 is added to 2 expect 4
Result: Success

[comfyneet]

Additionally after source generator feature is implemented, we can get Intellisense and static typing when interoping with data that allow spaces in identifiers, e.g. WorldBank, Json, Freebase, etc,...

[Unknown6656]

And it would not require any CLR changes, as it is already supported by the CLR!

---

by the way: Merry Christmas!

[Joe4evr]

Duplicate of #709 (which itself was a dupe of dotnet/roslyn#8542)

[MkazemAkhgary]

There are things called documentation, annotation and comment. have you tried them?

[TestMethod, TestCategory("category")]
void Test_01_Addition()...

or you can request for additional attributes. maybe there are some attributes already that I'm not aware of.

or

/// <summary>
/// describe things here. it will show up in intellisense. 
/// <summary>
[TestMethod]
void Test_01_Addition()...

And it would not require any CLR changes, as it is already supported by the CLR!

@Unknown6656 I don't know much about CLR but I would be surprised if it wasn't supported. I don't see how it is related to CLR anyway.

@comfyneet
compiler could allow you to start names with numbers or have spaces within. but its disallowed because these are just naming rules to help compiler easily understand identifiers without any sort of confusion.

This proposal breaks those rules. don't name methods like that or if you will, then don't expect compiler to worship you!

there are better ways, like using annotation, documentation or comment if you will.

this article might be helpful for you. https://en.wikipedia.org/wiki/Naming_convention_(programming)

[iam3yal]

@comfyneet,

There are at least two "challenges" with this feature:

1. It would be really frustrating/annoying to see APIs design with this feature in mind as it looks out of place when you contrasts it with the .NET ecosystem and changing conventions and introducing new ones is improbable.

2. It would only serve testing and there's already tools that do fairly well, one that I use on daily basis called Xbehave and you can see real world examples in the link @Joe4evr provided.

Now, I'd be glad to drop Xbehave and use this just for testing but then when I really think about it, it comes down to whether the language allows me to express the things I think about or need to achieve in a natural and readable manner and it does thanks to the tools I use so it comes down to the question of why would I replace the tools I use today with something like this and the answer is as follow:

1. It reduces the dependencies I have in the testing project but then it's really not a big deal to add it, I mean, it's literally just Install-Package Xbehave, however, I understand that some people don't have the privilege to use just any 3rd-party tool they find.

2. It reduces maintenance times because sometimes the library won't do the exact thing you need so sometimes you need to mess about to get it work but in the case of Xbehave, there's no configuration or anything like that so it really works for me but there's always the learning curve issue so this might increase development time and overall costs.

3. It will remove some of the boilerplate these dependencies introduce from the tests.

Finally, regardless to all of these points I really have hard time imagine the C# team approve such a feature but I've been wrong before so go figure. 😄

p.s. Sorry for mentioning Xbehave too many times, looks like I'm doing PR but I thought to share my own experience and how I solve this problem today.

[comfyneet]

its disallowed because these are just naming rules to help compiler easily understand identifiers without any sort of confusion. This proposal breaks those rules.

@MkazemAkhgary I don't understand how this suggestion would confuse the compiler at all, because the identifiers are enclosed in the backtick marks.

It would be really frustrating/annoying to see APIs design with this feature in mind as it looks out of place when you contrasts it with the .NET ecosystem and changing conventions and introducing new ones is improbable.

@eyalsk It probably doesn't contrast the .Net ecosystem as it also has the F# language, currently we can't call F# ticked functions directly from C# code without using the attribute [<CompiledName("FunctionName")>].

Also, in my opinion combining this breaking change with source generator feature will help us work with loosely structured data easier.

[axman44k]

@comfyneet I and others have suggested this feature some time ago because I agree and think it would really help the language. #709. I also suggested allowing any character and keywords along with spaces between the tick marks. Then you could have numbers, hyphens, spaces, symbols and more for identifiers.

static class `Workout Equipment`
{
static string `Cost and Value`;
static string current_naming_style;
static string CurrentNamingStyleToo;
static string `Derived Works`;
static double `350 Dollars`;
static string `Item-Description`;
static string `Product-Value_spec`;

static void `Begin Workout`()
{

}

static void `Begin-Item-Init`()
{}

}

`Workout Equipment`.`Cost and Value` = "30%";
`Workout Equipment`.`Derived Works` = "Sample works string value here";
`Workout Equipment`.`Begin Workout`();
`Workout Equipment`.`350 Dollars` = 350;
`Workout Equipment`.`Item-Description`= "Parts for working";
`Workout Equipment`.`Product-Value_spec`="time, value, cost";
`Workout Equipment`.current_naming_style = "current naming style with underscores";
`Workout Equipment`.CurrentNamingStyleToo = "current naming style pascal/camel case";
`Workout Equipment`.`Begin-Item-Init`();

[iam3yal]

@comfyneet So show me APIs in the FCL that have spaces in them outside to F#.