Hacker News new | past | comments | ask | show | jobs | submit login

Adding features for the the subset of developers that need optional performance enhancements is great. However, it does seem ripe for misuse. As in the developer who makes everything a ref reference because they read it makes it "faster." Would there be a way to get Visual Studio to warn about this?



Sure. Write a Roslyn analyzer to help out here.

Note: it's not like you can just sprinkle 'ref' on the return type of your methods willy nilly. Like 'ref'/'out' parameters, it requires you to do very specific things to keep your code safe/legal. As such, it's unlikely to just be added by people because, by and large, most code won't be equipped to actually handle it properly.

The codebases that will want to use this are already ones that have done a lot of work that makes them amenable to ref. i.e. game engines where you have large arrays of structs that you want to operate on in an efficient manner and whatnot.


I think it's great that you guys are adding a lot of high performance features that are beneficial to game engines. Any news you can share with us on a certain very-popular-game-engine-running-a-very-old-version-of-the-clr? ;)


Not .NET developer here but the usual way is to use some sort of linting tool to "disable" the esoteric features.


These tend to become cargo cult practices, "thou shalt never" that get in the way of those few places where they are useful.


I don't think so. The purpose of compiler warnings, lint-like tools, static analyzers and such is to bring developer attention to some block of code. Not 'Hey, you should not do it this way', but 'Hey, is this thing here as intended by you or just a typo or mistake?'.

I like the way its implemented in Perl. Use 'use strict' by default, and guard the block where you really need something unusual by 'no strict something' - refs, vars, subs - so neither compiler nor people reading your code never being confused whether is it a mistake or author's intention.


In C# one can always

  #pragma warning disable ${list of warnings}
and

  #pragma warning restore ${list of warnings}
https://msdn.microsoft.com/en-us/library/441722ys.aspx

Although frankly the list of warnings to disable and restore consists of warning numbers, not names, which is not super convenient.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: