Quick C# quiz

[Sander Rossel]

I'm so confident I file a bug report when the compiler refuses to compile MY code :laugh: Inspired by Chuck Norris, who doesn’t get compiler errors, the language changes itself to accommodate. Seriously though, style is (somewhat) important and I think your question is a great example of how having consistent styling can make reading code so much more easy :) You're probably wondering because you somehow need to parse/lex/tokenize it, in which case the other person was right, you write for compilers (maybe that's what he meant) :laugh:

Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

That's because Chuck Norris doesn't code in C++, C++ codes in Chuck Norris. Style is important and if I had my way I'd make my little parser enforce my own naming conventions as it would be a bit easier on me. But I'm not here for that. I'm here for you and I each being able to use this thing how we want, even while fighting with each other over how to use it properly. :laugh: I used to use hungarian notation. Now I've evolved to not bother with that, and instead focus on other things because of tools like intellisense. I always try to code in a way that works well with the tools I use and that looks at home with the tools I use. That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions than my C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase. Context is everything.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Sander Rossel]

honey the codewitch wrote:

That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions

I could agree there if I (and my team) always used the same tools. Which I (and formerly, we) do, so my style is adjusted to VS2012+. If I sometimes used VS2019 and other times VS Code and they somehow had different styles then I'd still stick with one style.

honey the codewitch wrote:

C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase

That's just common sense. Or did you think me some barbarian who uses PascalCasing in JavaScript as well!? :wtf: I've seen JavaScript written like it was C# and it really hurts the senses :sigh:

Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

We at least agree on that much, bracing notwithstanding

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[PIEBALDconsult]

Privates get lower-case; all others get Pascal casing,

[PIEBALDconsult]

For instance: Implanting Common Code in Unrelated Classes[^]

[BillWoodruff]

Thanks, for your educational response ! The article, and comments/discussion, was interesting; imho, the technique you show is too esoteric for someone who is not C/C++ highly literate, like me. I am reminded, by your article, of using a factory class to spit out different flavors of stuff depending on input parameters/types. cheers, Bill

«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali

[JohaViss61]

It is the C# equivalent of FUBAR. It means, just like the body bags coming from Vietnam, do not open. (the Class)

[Stuart Dootson]

I have a suspicion that C++ is equally reliant (possibly more so when you get templates involved) on type information ```C++ int a(int x) { return x + 1; } auto b = [](int y) -> int { return y + 1; }; struct C { int operator()(int z) const { return z + 1; } }; C c; class D { int d(int x) const { return x + 1; } static int e(int x) { return x + 1; } public: void do_stuff(int a_number) { a_number = a(a_number); a_number = b(a_number); a_number = c(a_number); a_number = d(a_number); a_number = e(a_number); y = a_number; } int y; }; ``` 5 'callable things', all of which meet the [C++20 `invocable` concept](https://en.cppreference.com/w/cpp/concepts/invocable), but are of different types (Yes, `d` can only be called as if it has one parameter from the context of a method of `D` or a derived class, but that's the example context I've used!). And then if you use `if constexpr`, that will also impact how you interpret the program: ```C++ template struct bit_field_t { : : // Other methods : : auto get_value(uint32_t from_field) { if constexpr (Size == 1) { // Return a Boolean if Size == 1 return (field & (1<>Offset) & ((1< 1 | x -> x * fac x (* even and odd are inferred to have type int -> int *) let rec even n = match n with | 0 -> true

[Stuart Dootson]

Some languages *do* use casing to differentiate between different classes of name. Haskell requires types to start with an upper-case letter, values (and functions are just values of course) to start with a lower-case letter and if you stray away from that, a compiler error is raised. Rust has a convention with similar rules, but raises a warning not an error if you break it.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[englebart]

Chanting: ELSEIF ELSEIF ...

[honey the codewitch]

and i otherwise love haskell but i'm not a fan of that.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Lost User]

Action fooAction ...

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

[honey the codewitch]

if you're suggesting my naming conventions aren't any good in the example I'd agree. The point however, is that it needs to parse regardless, or it's not C# :)

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Steve Naidamast]

I don't see it that way and I am a VB.NET programmer but also fluent in C#. :laugh: It is amazing how many people really view C# as some completely different type of animal than that of VB.NET... To me, the line of code was calling the method, "foo", with a string parameter...

Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com

[zezba9000]

"I know C family languages require type information to parse (which is unfortunate) but C# takes it to another level. in for a penny, in for a pound I guess." Static typing allows you to avoid runtime errors, its loads faster and much easier to find what is part of what. Sounds like you're coming from javaScript which teaches you how to think about things very wrong. A delegate in C# is a multicast-delegate in that when it invokes, its actually invoking a generated method that invokes the first function pointer, then the next and so on. It will always use virtual dispatch and can't be inlined. Don't use delegates for everything and only use them for what they're actually meant for.

[honey the codewitch]

No. I have a c++ background. I'm not talking about static versus dynamic, versus duck typing. I'm talking about parsing, an entirely different thing.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[zezba9000]

ic, sry about that

[honey the codewitch]

It might be my fault. Let's see if I can explain better: Say I'm parsing C# and I encounter the following: Console.WriteLine(Int32.MaxValue); My parser can interpret Console as a field, property, method, variable or type. Any one of them is valid here, but we can't know which it is without having type information during the parse. Similarly: Also WriteLine(Int32.MaxValue) could be a delegate invoke on a field, or property reference, or it could be a method call. You can't know during the parse without type information. That's what i mean by needing type information during the parse. It's not that strong typing is bad. It's that requiring type information during a parse dramatically complicates parsing. What I do, is I create multiple trees on a single parse, and then resolve which tree it is after i have the type information for it. Some other parsers (like microsoft's research C# GLR parser) do that too, but it's not easy. The other option is to preparse, but only up to the member definitions (ignoring method bodies and such) and then parsing again once you have all that info.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[zezba9000]

Not something I've thought about much but Is this for a lesson you can't use Roslyn for? I'm not sure how Roslyn handles using-static/type-aliases.

using static System.Console;
namespace MyNamespace
{
class Program
{
private delegate void WriteLineFunc();
private static WriteLineFunc WriteLine;

	static void Main(string\[\] args)
	{
		WriteLine();// delegate is used
	{
{

}

So if a local, field/method isn't found mark the AST node as un-resolved or add it to an un-resolved list. Then after all files are parsed go through the un-resolved nodes and try to resolve them through the aliased types. Then you don't have to parse over and over if my thinking is correct.