Letters from Readers

Letters: The Good, Bad and Ugly of C#

Readers respond to C# Corner columnist Patrick Steele's look into the best and worst of the C# programming language.

This is a great compilation. One thing I'll add on the try/catch block -- that I think we as Microsoft developers miss -- is the need to throw the original exception.

Or we need to stuff it in an inner exception and then throw it as a custom exception. Wrapping exceptions preserves the original downstream stack trace and gives the developer the opportunity to throw a meaningful exception -- -perhaps with more information in the form of properties -- beyond something as generic as an argument exception. This by no means is meant to advocate overuse of custom exceptions, but they also have their place and, in my experience, don't get used enough.

Tim Ellison
Richmond, Va.

Every programming language that gives you a lot of flexibility and power has bad and ugly things. That's not the fault of the language -- it's an inevitability. We learn to avoid doing things in bad and ugly ways.

Jim Perry
posted online

I'd like to thank Patrick for these timely reminders. I'm going to audit my current project for these issues today. If I may, I'd like to nominate "Bad Grammar and Spelling" to his list of "The Ugly." It's a real pain to try to understand C# code -- or any code -- that has comments and messages that are awkward, too terse or error-riddled. For instance, the first example in "The Bad" should throw a nested BadGrammarException (a recent invention of mine), as a better description for the exception would be "The amount cannot be negative" or "The amount must not be negative."

As developers, we often forget that ordinary people and late-night programmers are trying to use our software. We must make our programs easy to read, especially when errors occur.

As a final example, consider the difference a single comma makes between "Let's eat, Grandpa!" and "Let's eat Grandpa!"

David Patow
posted online

Nice list. But I think properties should have been listed under bad. They're misleading because to the user of a class they look like variables, but they're methods. Getting a variable will not change a class' state, assigning a value to it will only change that specific variable -- and in exactly the way you tell it to. With properties these guarantees are gone -- even getting one could change the state of the class. Awful. Properties should be ditched. Use methods instead.

J.C.
posted online

About the Author

This story was written or compiled based on feedback from the readers of Visual Studio Magazine.

comments powered by Disqus

Featured

  • How to Create a Machine Learning Decision Tree Classifier Using C#

    After earlier explaining how to compute disorder and split data in his exploration of machine learning decision tree classifiers, resident data scientist Dr. James McCaffrey of Microsoft Research now shows how to use the splitting and disorder code to create a working decision tree classifier.

  • Microsoft: Move from Traditional ASP.NET to 'Core' Requires 'Heavy Lifting'

    There are plenty of reasons to move traditional ASP.NET web apps -- part of the old .NET Framework -- to the new cross-platform direction, ASP.NET Core, but beware it will require some "heavy lifting," Microsoft says.

  • Purple Blue Nebula Graphic

    How to Compute Disorder for Machine Learning Decision Trees Using C#

    Using a decision tree classifier from a machine learning library is often awkward because it usually must be customized and library decision trees have many complex supporting functions, says resident data scientist Dr. James McCaffrey, so when he needs a decision tree classifier, he always creates one from scratch. Here's how.

  • Blazor's Future: gRPC Is Key

    Blazor guru Steve Sanderson detailed what Microsoft is thinking about the future of the revolutionary project that enables .NET-based web development using C# instead of JavaScript, explaining how gRPC is key, along with a new way of testing and a scheme for installable desktop apps.

  • Don't Do It All Yourself: Exploiting gRPC Well Known Types in .NET Core

    If you're creating business services that send dates and decimal data then you may be concerned that gRPC services don't support the relevant data types. Don't Panic! There are solutions. Here's how to use them.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events