• Guus (unregistered)

    There is, however, a pretty good chance that this will shut down the application as advertised. Something something StackOverflowError.

  • (nodebb)

    That camelCasing is being used for the method names in C# code is also unnerving.

  • Alex (unregistered)

    Clicked on that google search link, and thought 'huh, google thinks it's mispelt?' It took a worrying amount of clicks for me to realise…

  • (nodebb)

    Ehm, that's super weird, C# has never ever use camelCase naming for methods or properties, so to me this looks more like Java code. And it's weird for another additional reason, it will trigger an recursion warning too, so it's pretty hard to not spot the issue instantly in .net.

    Addendum 2026-03-10 07:56: Oh and when it comes to tail calls, C# will never have tail optimization due to compatibility issues. That was mentioned multiple times by various language designers at MS (including Mads IIRC).

    Addendum 2026-03-10 08:19: Oh, I just notice that even the comment is weird. XML comment look different, otherwise I have never seen anyone using triple slashes before in three lines.

  • (author) in reply to MaxiTB

    Yeah, I went reading to confirm- I knew C# didn't have tail calls, but that the CLR supported it. I was curious if they'd added it, but didn't expect that they had. The arguments I saw from Microsoft devs were more around "the tail call instruction in the CLR is more expensive than you think, and the benefits we get from the optimization aren't big enough to justify it."

  • (nodebb) in reply to MaxiTB

    C# has never ever use camelCase naming for methods or properties

    This is false. I haven't written much C# but the C# I did write used camelCase for naming methods and properties. That's least one counter example to your "never ever".

    It turns out that camelCase and CamelCase are just conventions and C# doesn't care.

    Addendum 2026-03-10 08:56:

    I just notice that even the comment is weird.

    It's a commenting style that Doxygen can use (also Apple DocC but that isn't relevant since this is definitely not Swift).

  • (nodebb)

    Please, dromedarCase and CamelCase.

    And maybe the /// is residue of conversion from VB.NET function description:
    https://stackoverflow.com/questions/5717359/how-to-add-description-to-functions-and-function-parameters

  • (nodebb) in reply to jeremypnet

    This is false. I haven't written much C# but the C# I did write used camelCase for naming methods and properties.

    Naming conventions are the same since the beta even before the launch of .net framework 1.0. So VS or any competent UI would have shouted at you constantly. If you change the fundamental coding style conventions, then the UI will shout at you for every every external code method.

    https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names

    It's a commenting style that Doxygen can use

    Doxygen is only a single tripple slash and even then it was really used since .net framework has support for XML comments again since the beta. It's way more common in non-.net languages.

  • (nodebb) in reply to Remy Porter

    Yeah, I went reading to confirm- I knew C# didn't have tail calls, but that the CLR supported it

    Well, the IL has support for it, the CLR is the runtime. TAIL is an ngen directive, so the native compiler that translates IL to assembly will respect it. .net IL will be compiled in assembly once and executed, the CLR is similar to the C/C++ runtime, just a collection of precompiled basic functions. That's the main big difference to Java, which is mostly interpreted and sometimes hotspot compiled (which is cached interpreted output in practice) - so you have actually constant translation going on vs .net's compile-once. There are a few exceptions for both, cause both languages support DPGO, so basically compiled code can be discarded and recompiled specialized to reduce vtable calls. And that's basically where in .net the recent idea was to also optimize tails, because you can ensure there will be not legacy pain points.

    The arguments I saw from Microsoft devs were more around "the tail call instruction in the CLR is more expensive than you think, and the benefits we get from the optimization aren't big enough to justify it."

    Yes, that is true. Not only that but there is actually not as much benefit to it than people think. You need to specifically write your code sometimes in a very unreadable way to make it work, so refactoring becomes a nightmare. Plus simple things like auto-boxing can prevent optimization even though it looks like there should be optimization, so it's easy to end up with non-optimized code and when you rely on it, you end up with breaking changes, not just performance issues.

    And finally, there is little benefit to it because where it would matter the most, in low level code (so basically standard libraries), nobody ever put in the effort in the first place. So not only would you have to rewrite a ton of code but also it would mean a ton of broken contracts because to make it work you would have to often adopt method signatures as well.

  • (nodebb) in reply to MaxiTB

    Naming conventions are the same since the beta even before the launch of .net framework 1.0. So VS or any competent UI would have shouted at you constantly. If you change the fundamental coding style conventions, then the UI will shout at you for every every external code method.

    I believe this is possible to override these days with a .editorsettings file such that VS will not complain, but if someone joins my team and want to use such a style I will very much complain at them for not sticking to the very well established convention as there is absolutely no reason not to except for "personal preference", they may not mind wasting their time in applying such pointless changes to the defaults, but I would not inflict it on myself, others on my team or any future users of the code base.

    When it comes to style for C#, the objectively best is the default of the IDE you use as it means zero set up time on new projects or for new joiners. I recognize this is simpler in C# where there is only really VS and Rider, so may not apply as easily to other languages.

  • Conradus (unregistered) in reply to Alex

    Remember when Googling "French military victories" would elicit the suggestion "Did you mean French military defeats?"

  • (nodebb) in reply to MaxiTB

    Conventions? You think someone writing this code will follow conventions?

  • (nodebb) in reply to Jonathan Lydall

    I believe this is possible to override these days with a .editorsettings file such that VS will not complain

    There is only support for one convention or another to my knowledge. But honestly I haven't messed around in the style guide options for nearly a decade since _ became the defacto private field convention, the only change in 25 years, replacing the old m_ and s_ notation since .net core but used by a lot long before that. So basically if you don't go with the standard, the IDE will complain about every other code you pull from nuget.

    When it comes to style for C#, the objectively best is the default of the IDE

    There is actually no "default IDE" style, all IDEs have by default followed the naming conventions, even small projects in encountered in 25 years.

    there is only really VS and Rider

    There actually have been tons and many are still around in one form or another. Borland had an IDE, there was MonoStudio, MonoDevelop, SharpDevelop, there is SharpIDE and ofc VSCode. Just to name a few I personally used. All of them used the official naming conventions, some of them didn't even had support to change them and .editorconfig itself is a very recent format. VS and Rider are just the most feature complete packages, both with pro/cons, so they dominate the professional market.

  • (nodebb)

    Shutdown via this mech can't be due to a stack overflow because .... "nobody uses StackOverflow any more"

Leave a comment on “To Shutdown You Must First Shutdown”

Log In or post as a guest

Replying to comment #692916:

Log Out

« Return to Article