Use Grave Accent(`) keyboard character to enhance code syntax.

[axman44k]

Use Grave Accent(`) keyboard character to enhance code syntax.

• Proposed

Summary

I would like to propose c# utilize the Grave Accent (`) Unicode character U+0060 as a way to enhance the language’s current syntax/naming convention limitations for keywords, functions, class names, variables etc... This would provide the added benefit of improving code readability, developer performance in addition to providing reduction in common coding tasks and errors.

Motivation

Currently many of today's c# programmers use mainly either of two naming conventions or a combination to write their code. These typically involve using the underscore character ("_") or mixed case of upper and lower characters (camelCase/PascalCase) to describe names of variables, classes, functions etc.. Over time as the project grows and additional developers are added or leave these names can become less meaningful, cryptic or restrictive. The proposed additional character in the language provides a subtle way for developers to write code without these development syntax limitations by providing new way for developers to "escape" the names / enhance the syntax and provide natural legible meaning to the code organically.

Detailed design

The Grave Accent character was chosen for a few key main reasons.

1. It is on many keyboards across multiple languages.
2. It is a fairly subtle character when displayed on the screen in various fonts.
3. It is easily accessibly from the standard keyboard

Please see below how the character could be added to the c# language.

Example 1 (Before)

Current Mixed Case Naming/Syntax Method:

public class HelloWorldClass
{
   public static void MainMethod()
   {
      var HelloWorldMessage = "Hello World";
      Console.WriteLine(HelloWorldMessage);
   }
}

In the above notice how the class, methods and variables has to be parsed mentally to identify where the uppercase starts and ends ...then read it as separate words to gather the meaning.

Current Underscore Naming/Syntax Method:

public class hello_world_class
{
   public static void main_method()
   {
      var hello_world_message = "Hello World";
      Console.WriteLine(hello_world_message);
   }
}

In the above notice how the class, methods and variables has to be parsed mentally to identify where the underscore starts and ends ...then read it as separate words to gather the meaning.

Example 1 (After)

New Grave Accent Syntax option:

public class `Hello World Class`
{
   public static void `Main Method`()
   {
      var `Hello World Message` = "Hello World!";
      Console.WriteLine(`Hello World Message`);
   }
}

In the above notice how naturally and quickly it is to 1) read the character to signal to the developer that it is part of the syntax despite shown next to string's quotation syntax; 2) A subtle character that allows for the reader to read the various names of the code's syntax without much effort; 3) Ability to gather meaning of the code through reading it as is by providing somewhat of a hybrid mixture of comment and code (as enhanced in below's example).

Other Examples:

static class `Workout Equipment`
{
 static string `Cost and Value`;
 static string `Derived Works`;
 static double `350 Dollars`;

 static void `Begin Workout`()
 {
  
 }

}

`Workout Equipment`.`Cost and Value` =  "30%";
`Workout Equipment`.`Derived Works` = "Sample Works";
`Workout Equipment`.`Begin Workout`();
`Workout Equipment`.`350 Dollars` = 350;

In the above notice how the variable 350 Dollars can be implemented with a beginning numeric value or any other character. Also the meaning of the code is enhanced without the need to decode the syntax.

Alternatives

Other alternatives could be the use of another keyboard character.

[HaloFour]

In my opinion, spaces in the middle of identifiers is an awful idea. In many languages where it is possible it is considered a bad practice (e.g. SQL). I personally don't find it more readable. Quite the contrary, it completely interferes with how I normally parse syntax given that it's much easier to spot spaces than it is to try to scan back and forth to try to determine whether or not that space is meaningful or just part of an identifier name.

[svick]

I don't think allowing spaces in identifiers in general is worth it on its own. I don't think it's actually harder to mentally parse PascalCase than it would be to parse `backticked identifiers`, except maybe for programmers who are only just starting and so are not used to this style. And for those, I think having two different syntaxes is more confusing than having one that has unnatural (to them) restrictions.

Also, using this syntax everywhere goes against existing naming conventions in .Net, so it would make your code inconsistent with pretty much all other .Net code (including the BCL).

On the other hand, I think there are special cases where this would be useful:

• Better interop with F#. F# supports identifiers with spaces using double backtics (e.g. let ``variable with spaces`` = 42), this would make such identifiers accessible from C#.
• Better interop with formats that allow spaces in identifiers, like JSON or CSV.
• There are cases when PascalCase does become awkward, like when writing unit tests with long names. Unit tests in F# are commonly written this way.

To sum up, I am for adding this feature, with the understanding that it's not meant to be used everywhere, only where appropriate. (But of course nobody would prevent you from using it everywhere.)

[dnperfors]

F# interop is the main reason for me to support his proposal.
We use F# for our domain model, which is extremely readable for the domain experts who don't have any programming experience. In DU's we often use spaces in the names to make it easier for the domain experts.
However in C# we can't consume these DU because of those spaces. Therefore having support for this would be very useful.
Besides that, the IL already supports it, so it wouldn't take a lot of effort to put it in. I would agree that you should be able to use coding guidelines to disable the feature.

[jnm2]

I_write_test_names_in_sentence_case_with_underscores.

It would take some getting used to. I can't tell if I would like it or not.
If this feature was available I'd use it solely for test names.

[Joe4evr]

This is essentially a dupe of dotnet/roslyn#8542

[axman44k]

I would like to add that although in the examples posted I did not demonstrate other characters besides space (" ") between the grave accent (`). It would be completely possible to add them for example the hyphen/minus "-" or tilde "~".

var `my-VariableName`  = 30;
var `my-variablename`  = 30;
var `my-variable-name` = 30;
var `my-variable name` = 30;
var `my-variable_name` = 30;
var `my~variable_name' = 30;

or a colon and space for method names

void `test: method_name`()
{

}

`test: method_name`(); // caller
 

Please note that this is only an additional option for those that wish to use it. Developers can continue to use underscores and mixed case for their identifiers. I understand that a few developers may be used to their current workarounds but please see how much more options for names become available to a developer with this feature.

Also remember the current restrictions on identifiers that exist are mainly because there is no other choice to tell the compiler that you would like to use other keyboard characters without it mistaking it for part of the language syntax .

[axman44k]

@jnm2 Your test names could now become any of these or stay the same:

`Test name that is long`
`test: name_that_is_long_just_because'
`[1] Testing name that is long like a sentence.`
`(1) Testing name that is longer`

etc...

[jnm2]

Why stop there? They could be multiline in case you need to write a paragraph. ;-)

[miloush]

3. It is easily accessibly from the standard keyboard

What is the standard keyboard?

1. It is on many keyboards across multiple languages.

"Many" might be not enough. It is on about half the number of layouts that have {

[jnm2]

On GitHub we'll have to type `` `My method name` `` instead of `MethodName`.

[iam3yal]

@axman44k There are all kind of tools that are available and allows you to use strings or even plain text for tests and really I like the way the test below reads so not sure I'd change that to what you propose because the names of the functions for my scenarios tend to be fairly short and in my opinion readable enough.

[Scenario]
public void EmptyKey(Exception ex)
{
	"When the key is empty"
		.x(() => ex = Record.Exception(() => {
			var collection = new ModelCollection<FakeModelWithKey>();
			var value = collection[""];
		}));

	"Then an argument empty exception should be thrown"
		.x(() => ex.Should().BeOfType<ArgumentEmptyException>());
}

Or slightly lengthy one like this:

[Scenario]
public void XmlCommandRootElementConversion(XmlCommandRootElement xmlCommandRootElement, IModelCollection<ICommandModel> collection)
{
	"Given an XML command root element with existing child elements"
		.x(() => xmlCommandRootElement = new Fixture().Customize(new RecursiveCustomization {
			MaxDepth = 1,
			MaxElements = 2
		}).Create<XmlCommandRootElement>());

	"When the root element is converted into a command model collection"
		.x(() => collection = XmlCommandConverter.ToCommandModelCollection(xmlCommandRootElement));

	"Then the collection should contain two command models"
		.x(() => collection.Should().Contain(c => c.As<CommandModel>() != null).And.HaveCount(2));
}

p.s. In the past I actually thought about proposing this sort of idea so I'm not really against it but outside to testing I don't really find this useful enough but then like I said there's all kinds of good testing tools available that turn this feature less useful or needed at least for this kind of use-case.

[DavidArno]

@eyalsk,

Tests are central to my approach to writing code, so "it makes writing good tests, easier" takes a proposal from -100 to +100 instantly, in my view. I'd love to be able to write a test like:

[Scenario]
public void `Given an XML command root element with existing child elements,
             When the root element is converted into a command model collection,
             Then the collection should contain two command models`()
{
    ...
}

But I know the vast majority here do not share my views on "it makes testing easier" being a reason, in itself, to make a language change. I've 👍 'd the proposal, but accept it'll never happen...

@jnm2,

Why stop there? They could be multiline in case you need to write a paragraph. ;-)

I appreciate you are expressing horror with those words, but I actually would find multi-lined identifiers useful for describing tests (as above). So I see this as a sensible suggestion on your part and agree with it. Sorry! 😊

[HaloFour]

@DavidArno

But I know the vast majority here do not share my views on the importance of tests.

I'm sorry, but this is ludicrous. The [in]ability to include white space within the identifier of a method name doesn't remotely affect your ability to write or run tests and I find this insinuation that detractors don't value testing to be personally insulting. If you so badly need to see the text in sentence form then I would recommend either switching to or requesting that your test framework include a Description property in their marker attribute.

Update: @DavidArno backed off of his original wording.

Very few languages that I've worked with allow for white space in their identifiers but I've never found this a hindrance for writing tests. Aside from using PascalCase or snake_case to write long descriptive method names testing suites also often provide a place to stick a description. I prefer the class/method name to be a short and simple name that can quickly identify the test in question. If I need more detail I would refer to that description. To each their own but that seems like a Heckuva departure for the current language parsing rules to satisfy the stylistic preference of the few and generally in very isolated circumstances.

[DavidArno]

@HaloFour,

Hmm, poor choice of words on my part in that case. I meant that I see "makes testing easier" as a very strong reason, all by itself, to make a language change. I didn't mean that others don't value testing as much as I do. That would be a ludicrous and insulting claim for me to make. I'll edit my comment.

Comment edited. Hopefully it's clearer, and less insulting, now.

[alrz]

Given an XML command root element with existing child elements, when the root element is converted into a command model collection, then the collection should contain two command models

I think method name is a "title" for your test, not the description. neither is the above.

In fact, I don't see how that would help you, it won't even fit in a "test explorer" window when it fails, you would end up with an incomplete sentence that says "Given an XML command root element with" failed.

[jnm2]

@DavidArno

I appreciate you are expressing horror with those words

Not horror, more like hilarity. But I'm glad I was of some use. 😁

If this behaved consistently with C#'s existing multiline logic, you've just titled your test Given an XML command root element with existing child elements,\r\n             When the root element is converted into a command model collection,\r\n             Then the collection should contain two command models.

Could be fixed, obviously. Either way, I agree with @alrz. How do you browse quickly through a list of tests in a test explorer when each test name is wrapped to take an entire page to scroll past?

[iam3yal]

@DavidArno Like I said I'm not really against it but like @alrz said you took the whole scenario that can sometimes be even more complex and used it as the subject whereas the actual scenario is really a conversion from one thing into another. :D

However, if this was possible I could just write something like this:

[Scenario]
class `Xml command root element conversion` {
	
	private XmlCommandRootElement xmlCommandRootElement;
	
	private IModelCollection<ICommandModel> collection;

	void `Given an XML command root element with existing child elements`() {
		xmlCommandRootElement = new Fixture().Customize(new RecursiveCustomization {
			MaxDepth = 1,
			MaxElements = 2
		}).Create<XmlCommandRootElement>()
	}
	
	void `When the root element is converted into a command model collection`() {
		collection = XmlCommandConverter.ToCommandModelCollection(xmlCommandRootElement)
	}
	
	void `Then the collection should contain two command models`() {
		collection.Should().Contain(c => c.As<CommandModel>() != null).And.HaveCount(2)
	}
}

This is actually more appealing to me for few reasons:

1. I could probably use xUnit directly instead of another abstraction on top of it such as xBehave.Net` so it's less difficult to learn, there's less time spent on maintainability and migrating from one testing library to another might be easier because there's less coupling between the code I'm testing and the testing library I use.

2. It's a simple construct, there's no lambdas so there's less allocation involved here and less discovery/work that the testing library needs to do so it might also take less time to run all of the tests.

The only issue I see with this is actually the user experience, I'm not sure how I'd design an intellisense that works nicely with it. :)

All in all, I might use it after all. 😉

[axman44k]

@eyalsk Your example is an ideal use case. I think for intellisense it would be easier because it's only looking for the "`" character to know the proper context. You could also utilize this slight variation on the code to help visual perception...although not needed imho.

[Scenario]
class `201. Xml command root element conversion` {
	
	private XmlCommandRootElement xmlCommandRootElement;
	
	private IModelCollection<ICommandModel> collection;

	void `1. Given an XML command root element with existing child elements`() {
		xmlCommandRootElement = new Fixture().Customize(new RecursiveCustomization {
			MaxDepth = 1,
			MaxElements = 2
		}).Create<XmlCommandRootElement>()
	}
	
	void `2. When the root element is converted into a command model collection`() {
		collection = XmlCommandConverter.ToCommandModelCollection(xmlCommandRootElement)
	}
	
	void `3. Then the collection should contain two command models`() {
		collection.Should().Contain(c => c.As<CommandModel>() != null).And.HaveCount(2)
	}
}

[iam3yal]

@axman44k Yeah, one can do that if he wants, personally, I'll never tag my tests with a specific order and there's few reasons for that but this isn't the point or the place to make an opinion about it. ;)

Anyhow, I just thought to give a real world example of what some of us are using today and what we gain by having this feature but then dunno it feels too specific for a general language because like I said I don't know how I feel about this outside to the "testing department", regardless, I'd probably use it if we had it just for that.

Alternatively, well, it's not really an alternative and I really don't want to derail the discussion but because we're speaking about tests then I feel like it's okay so if we had free functions and we could also execute them outside to data structures or whatever then we could just do something like this:

The testing framework could define the following free function:

static void Scenario(string title, params (string title, Action action)[] cases)
{
}

And then we could use it like this:

Scenario("Xml command root element conversion",

	("Given an XML command root element with existing child elements", () =>
	{
		// ...
	}),

	("When the root element is converted into a command model collection", () =>
	{
		// ...
	}),

	("Then the collection should contain two command models", () =>
	{
		// ...
	})
);

Just a thought. 😉