DEV Community

Discussion on: The C# Language

Collapse
 
justinjstark profile image
Justin J Stark • Edited

I use C# primarily for business. It is a very good OOP language that is continually updated with new language features that make it better and better. C# is very popular in enterprise so there are tons of jobs available. The tooling around it is expansive; you can find open source and free tools for pretty much anything you want to do.

That said, my biggest gripe with C# and the ecosystem is it is anything but a pit-of-success. Most of the templates and advice new programmers are given (example: scaffolding) will get you up and running quickly but will invariably lead to messy situations of object reuse and tight coupling. You have to learn things the hard way like "every view should have its own view model in MVC" and "every integration should have its own DTOs". These run against the standard advice of DRY but they are very necessary. Otherwise you wind up with object-dependency-hell where a change in one part of your application blows up an unrelated part. To solve it, you wind up with tons of object and tons of plumbing/mapping code.

Null references are still one of the biggest causes of bugs in C#. There is finally a feature being worked on to make objects non-nullable but who knows when that feature will finally get introduced. And it's not going to be enabled for new variable declarations by default.

In order to accommodate the tools and language shortcomings you will use class properties everywhere. Unless you are very thorough and ensure all object creation is done through object constructors while encapsulating your properties, good luck ensuring your objects are all in valid states as your application changes through the years. Good DDD patterns with layers and encapsulation help, but again, it takes a ton of code and knowledge to pull off.

I wish C# had more compile-time checking. I wish I could use Clojure-style maps as function arguments with compile-time checking instead of having to define a query object (DTO) and a result object (DTO) for every consumable function working with complex data.

New programmers will write "services" that do a bunch of things when they'd be better off writing static functions or single-function-classes. Writing testable code in C# is way harder and requires a lot more code than some other languages. Dependency injection helps but the wiring is tiresome so then you have to learn IoC. Fine, but how much better off would you be had the language templates started you here.

These are just a few of the issues that are on my mind right now. The amount of knowledge you need to have and the amount of code you have to write in C# to create maintainable enterprise applications is mind-boggling. So many applications, especially those in enterprise, suffer from premature rot because the language pushes you toward writing code that is fast (cheap) but will haunt you for the lifetime of the application. A lot of newer languages have sprung up because of these exact language issues that aim to guide programmers to successful strategies from the start.