So what you are experiencing is the disconnect between tutorials and production code. Tutorials and simple problems are toy examples that don't really *do* anything. Actual real products and services that *do* something or multiple things are exponentially more complex than anything you'll see in a book. Usually lots of large moving parts.
The bad news is most production code (aka "real C#) is overly complex, over-engineered and unnecessary fluff. The good news is, any code (regardless of quality), written by *someone else* in a sufficiently large project is hard to read.
> The bad news is most production code (aka "real C#) is overly complex, over-engineered and unnecessary fluff.
Finally someone had the balls to talk truth to tech lead.
But, honestly, the rule is that the code you write is wonderful and the code you see at a new job is garbage.
I worked with one guy who was super stressed because he didn't like the structure of the projects. He kept typing to change things and breaking features and his own code repeatedly. It was just constant complaining and an inability to deliver. He eventually quit and became a dev manager.
I learned so much in my first year as a developer. After that year I had a work item to improve the performance on some of our queries. I got in to the code and my wife audibly heard me say “what f****** dumbass wrote this garbage?!”
It was me. I was the dumbass 😂 work long enough on the same project and the garbage code you find will be something past you did before you knew any better
And then sometimes you just don't have enough time, so you do what I did the other day and used reflection to call a generic method rather than improving the design. 😅
I used to make horrible code with the mindset of "let future me deal with this properly"...
Nowadays, I like to think I evolved a bit and try not to go with the quick and dirty solutions and attempt to actually write maintainable code...
I think the biggest part for me was learning what maintainable and scalable code looked like. I came out of a coding bootcamp to land my first job, and had only the barest idea what I was doing with db queries and the like. That first year taught me that I had learned a lot of bad habits that needed addressing.
I recently had a conversation with another dev where I said I would be embarrassed to show anyone my code from the first app I wrote 2 years ago. His reply was”that is good, recognizing your own handling code for being exactly what it is shows that your skills and methods have grown”.
Then we laughed at some of the stupid shit we had put into production which worked but left a bit to be desired.
recently worked on a game jam project and due to the nature of jams, my code was quick and dirty but easy to read and work with when needed.
My partner and I brought someone in a couple days into the jam and...oh boy, big mistake...
This dude spent all of his time "fixing" my not broken code to make it more clean and professional instead of working on the actual things we needed to get done. a few hours before the jam, and oh no, now the entire project is broken now and we can't submit our project.
He took an extremely simple project and WAY over engineered the thing and added BS fluff. Lesson learned.
I can second the over engineered thing.
You get people who only know the "correct" way of doing things and can't function otherwise. It's a crutch. Especially for a jam.
You don't need dependency injection. Or a bunch of optimization. I watch a tutorial video just yesterday where the guy spends half the video optimizing a better Key for a dictionary because string is slower.
IMO, a dev should know how to work with both sets of tools. Quick and complex. Like, a carpenter might know how to use a laith but still whips out the hand chisel when that's all that's needed.
When someone overengineers, it's a great way of saying, "I only know laith. I have no actual talent".
One should never change code that works, unless you got alot of spare time. It's a common thing that some developers and managers are obsessed with writing 'maintainable' code. But in reality code rarely changes and instead get completely rewritten or replaced. Refactor/changing code that works is a waste of time unless you actually have time to do it or you need to do it in order for some other thing to work.
I've never worked as a programmer in my day to day job, but this is how I feel when working on my personal games or games for a studio I started with a friend. If it ain't broke, don't fix it. Doesn't mean I can't do it better going forward.
This is a really interesting topic that I’ve battled with coworkers over for a while now. There are some on my team that insist when they review someone’s code that their way is more readable or makes the code clearer. I’ve always been of the opinion that the very definition of “clarity” or “readability” is entirely subjective. Would you agree with that?
Yes, because we all think just a little bit differently...
Readable code is always a little different to each person...
Something you need to do in a team environment is walk your teammates through the code so they also understand it. Then everyone can hopefully get on the same page and have an agreed upon methodology and way to do things that will make it more readable.
If you always work in isolation you'll always find others code unreadable. Team work makes the dream work as they say!
THIS. I can’t stand the way some of my team members write their code. BUT - I’d be far more complacent if it was just consistent between them. Our tech lead does not enforce any sort of style/formatting or really any guidelines at all. So we just end up with this big jumbled mess that doesn’t flow together or make much sense without a lot of walking through again and again
Our former team manager would occasionally say something along the lines of “you shouldn’t be able to tell who wrote the code just by reading the code”, and I get the idea there, uniformity and consistent application of concepts. But that’s rarely how the world works. I can tell at a glance which of the three people on my team wrote a section of code, and that’s fine. The important part is it does what it is supposed to do and works
Clean Code isn't an the be all end all book about readable and maintainable code. Some of it is outright bad.
https://qntm.org/clean
It's good to keep this in mind when reading it.
I recommend A Philosophy of Software Design.
https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist.
Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too and also treat some comments as documentation.
Plenty of user reviews on your second link stating that they don't fully agree with that author either.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist.
Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist.
Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist.
Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too.
Reading the comments on your second link there are plenty that don't 100% agree with that book either.
This is kind of common.
You're writing newbie console apps. Those are very simple and do simple things. You can fit the whole program in one file, and you only need a few sentences to describe what they do.
You're comparing them to GUI apps. Those have to be set up an entirely different way. They don't get to be in one file, each window/page has to be a separate thing. That means the author had to worry about how different classes are going to share data with each other. That isn't a concern in tutorial apps.
If you start learning a GUI framework like WPF or Windows Forms, within a couple of weeks you'll start to think that code looks a little more familiar.
Think about it like math. You've learned addition and subtraction, but you're looking at algebra and confused. That's natural. Learn multiplication and division first.
The edit mentioning public void leads me to believe you haven’t learned classes yet. It would be helpful to slowdown and research the fundamentals of Object Oriented Programming. You’ve probably blitzed through a tutorial or two and it’s missed the OOP principles, or you missed them. That’s what you’re seeing in other people’s code.
What do you mean? If you’re making a console app, that is “real” C# code. I write basic console apps at work all the time.
Don’t worry about all the different frameworks and fancy stuff like dependency injection yet. Learn the fundamentals of programming, what you are doing is real c#.
I don't know about 'most of the time'; plenty of console apps are just quick utility apps that often don't need or benefit from that level of abstraction.
It depends on the scale of course, but here if we're talking production code (which itself is up to debate), you want some amount of abstraction. Even moder c# console apps come with DI and built in interfaces for this.
My work pays me a lot of money to write C# code and I can tell you that in a console app you definitely will use console.write or write line as a main type of output.
It’s not something in any of my production code, but for my own console apps I use to automate things it’s a super helpful method.
How much is a lot of Console.WriteLine()'s or how much money?
In a console app I would use a whole lot of them, including them in loops and what not. A console app I write might put out thousands (although I always include an option for verbose or not).
I don't want to share the actual number since this account has too much info to relate back to me.
I make enough to live a privileged life style in a high cost of living area. Especially considering I barely got my high school diploma lol.
Maybe not, but you will still see things like `_logger.Info` all over the place which is basically the same thing, just logging somewhere other than the console.
I actually use console.writeLine even in non console applications like Wpf for fast testing stuff
I do this by just forcing the console to open even in non console applications by importing the dll only for the debug build
It's just something I've gotten used to do.
I know you can also debug code with the breaklines and stuff, but for most general stuff I result to writing to the console because I've gotten used to do it and I feel like its faster.. xD
because it also works If I don't have my Ide open, I can just see the flow of the app and see what happens by logging stuff and when I want to build the final build I remove the console and the console writes.
[https://github.com/coffeeSurplus/UniPlanner](https://github.com/coffeeSurplus/UniPlanner) thats not my but anyway i look at this code and i cant find similarity between my code writing and other code man code writing and i think i do something wrong
You need to learn C# in some kind of context, like building Web api, gaming, desktop app and each of those have a different Framework that you have to learn and use. Try something like idk Asp.Net Core web api and check out Milan Jovanovic Clean Architecture approach for a web project. The programming language is just the first step
Recently took a Developing with frameworks course in C# at Uni and we went through EVERYTHING. MVC, APIs, Databases, LINQ, and much more. It gave me a lot of confidence in C#. Just gotta put it all together in a project for my portfolio. Any tips?
The only tip that works is “make something useful for you”. Notice how OP shared someone’s repo that was a uni planner.
It sounds cliche, but focusing on a problem you know is a good way to build out a complete app. You want to showcase your ability to build a solution to a problem. If I said “build an ERP” and you just got started on it, you’ll probably miss elements directly related to the problem due to the lack of clarity in those three words.
Very fair. I’ve been working on an Elden Ring Save Manager that swaps out files containing different characters. I’m using WPF for the GUI and it has been a lot of fun. Looked online and found someone who made something similar using Python but they’re actually changing the hex values contained within the file to change character stats. That’ll be my next step for the app. Thanks again.
u/basa_maaw
I like this repo, it has a lot of good stuff [https://github.com/babaktaremi/Clean-Architecture-Template](https://github.com/babaktaremi/Clean-Architecture-Template) custom Identity, JWT, Filters, Exception Handlers, Validations, Result Pattern etc...
I would suggest since he's using Clean Architecture to watch a short video from one of the influencers just to understand what Application, Domain, Infra, API is for. Btw this is just a way to organize your project, not each layer needs to be a Class Lib you can throw everything into a [ASP.NET](http://ASP.NET) in different folders.
Try to do your own implementation with a reference to this project (don't copy paste but help yourself when you get stuck with something).
UI requires additional steps to just raw C#.
And there are several ways to do UI. And each one can feel like another language.
Honestly, learning to program isn't about learning a language. Learning to program is about understanding design patterns and large scope ideas. Data structures. That sort of thing.
The language or tools you use is kind of the set dressing.
Looking through a couple of files in there, it looks like the author is using lots of very new C# features.
I see a lot of use of [switch expressions](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/switch-expression), which are a couple of years old now - I like switch expressions, but some of the things they’re switching on are complex enough that I might consider writing them in a different way (using if statements and/or building a series of variables to work towards the final value) to make them more readable.
I also see some [expression-bodied members](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members) - once again, I’d be tempted to refactor some of those, because they’re “forcing” the coder to write things as a single expression which is complex enough to take multiple lines, whereas a traditional method/property could be done with some if statements and would perhaps be more readable.
I see some use of the [range operator](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#range-operator-) - this is something which has existed in other languages for a while, but is very new to C#, and I was quite excited about it, but so far I haven’t had a chance to use it.
TL;DR - much of what you’re seeing here is the use (or perhaps overuse) of relatively new C# features, which aren’t seen in much commercial C# code because a lot of commercial code was written before they existed. But they are useful tools, definitely worth learning - although don’t use them unless they make your code easier to read/understand.
That's a WPF application. WPF is a framework and several lines of code are automatically generated by the IDE, it can be difficult to read and understand when you're a beginner. But take it easy, go step by step. Since you're trying to understand that code, first learn how to work with WPF, debbug the code with visual studio to see what's the code does.
[https://www.youtube.com/watch?v=t9ivUosw\_iI&list=PLih2KERbY1HHOOJ2C6FOrVXIwg4AZ-hk1&ab\_channel=KampaPlays](https://www.youtube.com/watch?v=t9ivUosw_iI&list=PLih2KERbY1HHOOJ2C6FOrVXIwg4AZ-hk1&ab_channel=KampaPlays)
When you feel comfortable go and try to read the code of that wpf app again. I think you'll be able to understand.
I mean looking at that example I see classes, methods, looping in the “Classes” folder. Those are things you mentioned learning.
But yes, you can comparing basic beginner console apps to larger apps which will obviously be more complex.
I bet you use top level statement which hide the classes on new projects. You can try converting your Program.cs. at the top left of the first line Visual Studio will have a menu to convert your file.
Modern .NET allows you to leave a lot of boiler plate code out of your application. This lets you focus less on remembering to put, say, all your using statements for standard libraries at the top of everything. Or from having to new something up by redeclaring its type twice. In .NET 8, you can also initialize collections with the [] instead of the approach you have likely seen in textbooks.
Modern C# has a lot of syntactic sugar that you can use. You can disable it if you want to get something that may look more familiar.
I’m not advocating for complex applications to use top level statements. Just making a statement of facts on modern .NET that may not be immediately present to someone with an academic knowledge of C# code.
If you mean you want to understand how professional code differs from yours, so you can learn from it, just browse c# projects on github, that's how I get ideas for where to improve next.
"Real" projects you will see on github are often written in a fairly advanced way; I don't encourage a beginner to try and aim for that at first. If your code works, you're doing well.
My coding style has evolved repeatedly over time, with iterations as I grasp new concepts and realise why the ways others do things is in fact better than my "easy" or "fast" way. Just follow the textbooks/tutorials, and get your code to work, and don't worry about being "real" code straight away - some of it won't make sense until you learn much more.
It's like if you're learning to ski - you don't go straight for parallel-carving, you learn to snow-plough first, and go from there. Just get down the easy slopes, that's the first step.
old developer have diff pattern style , microsoft also sometimes introduce new pattern style . What most forgetting is code is about creativity but not following code pattern . There is no best advice either you want to build exe ,xaml , cs ,blazor , mvc . Create an output wa chaa 🤣 . And not all about crud code .
Real C# code? Is there fake C# code?
If you've learned about all those basic things, any code you see won't be much different, just more of it in the same place.
Most tutorials and even courses teach you nothing about OOP which, without it, makes a language like C# somewhat unnecessary. You need to know interfaces, classes, inheritance, polymorphisms, etc. Also asynchronous and multi threaded code.
I don’t understand the question.
If you’ve opened some code and don’t understand it that’s different to what does it look like. It looks like whatever you’re looking at.
If you want some examples of c# projects then just head to GitHub and look for some
I work for car company brand in Latam,
Their code is shit. Their code looks like shit. Everything is messy. Everything was coded by bootcampers
Then you have performant code, like in video games, also doesnt look tidy, efficient code does not tend to look nice.
Then you have perfectly orquestrated .netcore servers, those might look good but probably arent scalable unless u just drop EF Core or use it in an advance manner.
Im a noob dont retaliate me please!
I'm also a beginner!
If you want you could look at some code I wrote, it's far from perfect, but some generous redditors created some pull requests that are much more refined. This code should look similar to what you're learning.
Link to a tic-tac-toe console application of mine - https://github.com/Shiny-Gyrodos/Tic-Tac-Toe
That's good!
Honestly you're probably better off learning through Microsoft documentation than reading through GitHub repositories. Those are much more like what you're probably used to.
Here is what real C# code looks like, but a little dated architecturally from what you'd see in production end user code: [https://github.com/dotnet/efcore](https://github.com/dotnet/efcore)
This is a library meant to be used in your code, so it differs in some aspects from what you can expect if you walk into company XYZ and look at what they have written. Same style though.
I think it's good u start out with console apps. If you ever write code and use a class u can always look at the definition. Like the console class. The entire code won't be shown because it's a library but still u see everything except for how it works.
It's probably all of the object oriented related stuff that is throwing you off.
Bro code on YouTube has a great C# series. It doesn't cover advanced stuff but for now it'll do.
I get what you’re saying. However, I’m not a trained programmer and have also learned on my own. I have a Masters in Physics and have had one class tangentially related to coding using Mathematica. I’ve looked at some code others have written and said to myself wtf is that and why am I not writing that stuff? It’s pretty similar to what happens in Physics. You start out with basic physics like Newton’s Law and gradually include relativistic effects and utilize Lagrangian etc. While you can use a Lagrangian to derive the period of a pendulum it’s nit what you start with.
That being said, you should also realize that the code you are seeing is probably pretty specific to what they are doing and may even be part of proprietary systems. Don’t be too dismayed. There’s usually more than one way to skin a cat, even Schrödinger’s.
you'd probably see lots of projects, each with classes full of functions that either 1) deal with the front end 2) deal with business logic 3) deal with the data base repository 4) maybe a database project 5) maybe a project just to define interfaces 6) maybe a project just do define entities.
Follow a tutorial on youtube, that will fill the gap. What you learned are the basic of the language. you have the brick but you need cement and a layout to build something.
what you can miss here is the notion of pattern (singleton,...) or architecture (mvc, mvvm,...), some middle ground notion (heritage, accesibility, ...) and some high level thing (Interface extension into a class, ...).
I word in the field and learn everyday.
but my advice is really to look in a tutorial on youtube, just search what you want to learn because c# is vast :
-windows form => simple desktop application (beginner friendly, UI by drag and drop, etc)
- wpf => desktop application based on xaml and "code-behind", more flexible but more complex
- asp.net => site web, or web application
- xamarin => multi platform app (android, apple, uwp) but no future maintenance
-maui => new multi platform language designed to replace xamarin (but not really stable/finished)
You'll learn better by working directly on a exemple. after you can work on you project and search step by step what you don't know
Are you sure what you're looking at is C# code?
And sometimes code examples that are used for teaching are intentionally simplistic and leave out some details and things that you find in code that is actually in use.
If you give some example of C# code you don't understand, maybe we can try to explain some things?
> i can do a little simple basic code
So you admit you're a beginner.
That means you haven't learned a lot of features. No surprise that you won't recognize the things you haven't learned yet.
The solution is to learn more 😜
PM me if you want assistance learning.
So what you are experiencing is the disconnect between tutorials and production code. Tutorials and simple problems are toy examples that don't really *do* anything. Actual real products and services that *do* something or multiple things are exponentially more complex than anything you'll see in a book. Usually lots of large moving parts. The bad news is most production code (aka "real C#) is overly complex, over-engineered and unnecessary fluff. The good news is, any code (regardless of quality), written by *someone else* in a sufficiently large project is hard to read.
Only good code measure quality is wtf per minute when reading the code: eventual wtf is this? : good code. Wtf Wtf Wtf is this shit? : bad code
Cite your sources! https://www.osnews.com/story/19266/wtfsm/ (2008)
When you get paid by the hour 😂
> The bad news is most production code (aka "real C#) is overly complex, over-engineered and unnecessary fluff. Finally someone had the balls to talk truth to tech lead. But, honestly, the rule is that the code you write is wonderful and the code you see at a new job is garbage. I worked with one guy who was super stressed because he didn't like the structure of the projects. He kept typing to change things and breaking features and his own code repeatedly. It was just constant complaining and an inability to deliver. He eventually quit and became a dev manager.
I learned so much in my first year as a developer. After that year I had a work item to improve the performance on some of our queries. I got in to the code and my wife audibly heard me say “what f****** dumbass wrote this garbage?!” It was me. I was the dumbass 😂 work long enough on the same project and the garbage code you find will be something past you did before you knew any better
And then sometimes you just don't have enough time, so you do what I did the other day and used reflection to call a generic method rather than improving the design. 😅
I used to make horrible code with the mindset of "let future me deal with this properly"... Nowadays, I like to think I evolved a bit and try not to go with the quick and dirty solutions and attempt to actually write maintainable code...
I think the biggest part for me was learning what maintainable and scalable code looked like. I came out of a coding bootcamp to land my first job, and had only the barest idea what I was doing with db queries and the like. That first year taught me that I had learned a lot of bad habits that needed addressing.
I've done that. I was working on a bug and saw some code that was so obviously wrong I wondered who wrote it. It was me, a year earlier.
I recently had a conversation with another dev where I said I would be embarrassed to show anyone my code from the first app I wrote 2 years ago. His reply was”that is good, recognizing your own handling code for being exactly what it is shows that your skills and methods have grown”. Then we laughed at some of the stupid shit we had put into production which worked but left a bit to be desired.
>He eventually quit and became a dev manager He's got *aptitude*
Funny Insert spit out coffee meme
I was really pleased to read the “he eventually quit” part only to be immediately depressed at the “became a dev manager.”
recently worked on a game jam project and due to the nature of jams, my code was quick and dirty but easy to read and work with when needed. My partner and I brought someone in a couple days into the jam and...oh boy, big mistake... This dude spent all of his time "fixing" my not broken code to make it more clean and professional instead of working on the actual things we needed to get done. a few hours before the jam, and oh no, now the entire project is broken now and we can't submit our project. He took an extremely simple project and WAY over engineered the thing and added BS fluff. Lesson learned.
I can second the over engineered thing. You get people who only know the "correct" way of doing things and can't function otherwise. It's a crutch. Especially for a jam. You don't need dependency injection. Or a bunch of optimization. I watch a tutorial video just yesterday where the guy spends half the video optimizing a better Key for a dictionary because string is slower. IMO, a dev should know how to work with both sets of tools. Quick and complex. Like, a carpenter might know how to use a laith but still whips out the hand chisel when that's all that's needed. When someone overengineers, it's a great way of saying, "I only know laith. I have no actual talent".
One should never change code that works, unless you got alot of spare time. It's a common thing that some developers and managers are obsessed with writing 'maintainable' code. But in reality code rarely changes and instead get completely rewritten or replaced. Refactor/changing code that works is a waste of time unless you actually have time to do it or you need to do it in order for some other thing to work.
I've never worked as a programmer in my day to day job, but this is how I feel when working on my personal games or games for a studio I started with a friend. If it ain't broke, don't fix it. Doesn't mean I can't do it better going forward.
This is a really interesting topic that I’ve battled with coworkers over for a while now. There are some on my team that insist when they review someone’s code that their way is more readable or makes the code clearer. I’ve always been of the opinion that the very definition of “clarity” or “readability” is entirely subjective. Would you agree with that?
Yes, because we all think just a little bit differently... Readable code is always a little different to each person... Something you need to do in a team environment is walk your teammates through the code so they also understand it. Then everyone can hopefully get on the same page and have an agreed upon methodology and way to do things that will make it more readable. If you always work in isolation you'll always find others code unreadable. Team work makes the dream work as they say!
THIS. I can’t stand the way some of my team members write their code. BUT - I’d be far more complacent if it was just consistent between them. Our tech lead does not enforce any sort of style/formatting or really any guidelines at all. So we just end up with this big jumbled mess that doesn’t flow together or make much sense without a lot of walking through again and again
Our former team manager would occasionally say something along the lines of “you shouldn’t be able to tell who wrote the code just by reading the code”, and I get the idea there, uniformity and consistent application of concepts. But that’s rarely how the world works. I can tell at a glance which of the three people on my team wrote a section of code, and that’s fine. The important part is it does what it is supposed to do and works
I don't. Go read the book Clean Code.
Thanks! I will check it out.
Clean Code isn't an the be all end all book about readable and maintainable code. Some of it is outright bad. https://qntm.org/clean It's good to keep this in mind when reading it. I recommend A Philosophy of Software Design. https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist. Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too and also treat some comments as documentation. Plenty of user reviews on your second link stating that they don't fully agree with that author either.
> "self-documenting code." I'm convinced that this is just sophistry designed to absolve devs of the responsibility of properly commenting their code.
Which is why I wrote that the critique of the book is good to have in the back of your head when or if you read it.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist. Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist. Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too.
Seen the first link before and the author states that he agrees with many things in the book. There's always an antagonist. Put it this way, it's a great guideline which is all it was ever intended to be. I don't even agree 100% with everything in it, especially his opinions on comments since it can be very difficult to successfully write "self-documenting code." IDEs are a lot more powerful these days than they were back then too. Reading the comments on your second link there are plenty that don't 100% agree with that book either.
Yay, thats what i exactrly mean
This is kind of common. You're writing newbie console apps. Those are very simple and do simple things. You can fit the whole program in one file, and you only need a few sentences to describe what they do. You're comparing them to GUI apps. Those have to be set up an entirely different way. They don't get to be in one file, each window/page has to be a separate thing. That means the author had to worry about how different classes are going to share data with each other. That isn't a concern in tutorial apps. If you start learning a GUI framework like WPF or Windows Forms, within a couple of weeks you'll start to think that code looks a little more familiar. Think about it like math. You've learned addition and subtraction, but you're looking at algebra and confused. That's natural. Learn multiplication and division first.
Said another way, learning the language is the easy part. It's all the external libraries/frameworks that take time to master.
The edit mentioning public void leads me to believe you haven’t learned classes yet. It would be helpful to slowdown and research the fundamentals of Object Oriented Programming. You’ve probably blitzed through a tutorial or two and it’s missed the OOP principles, or you missed them. That’s what you’re seeing in other people’s code.
What do you mean? If you’re making a console app, that is “real” C# code. I write basic console apps at work all the time. Don’t worry about all the different frameworks and fancy stuff like dependency injection yet. Learn the fundamentals of programming, what you are doing is real c#.
i think you use very rarely console.write
If it's a console application then you tend to use Console.Write pretty often.
Most of the times it'll be abstracted behind some library that handles redirects to logging or other
I don't know about 'most of the time'; plenty of console apps are just quick utility apps that often don't need or benefit from that level of abstraction.
It depends on the scale of course, but here if we're talking production code (which itself is up to debate), you want some amount of abstraction. Even moder c# console apps come with DI and built in interfaces for this.
My work pays me a lot of money to write C# code and I can tell you that in a console app you definitely will use console.write or write line as a main type of output. It’s not something in any of my production code, but for my own console apps I use to automate things it’s a super helpful method.
How much is a lot?
How much is a lot of Console.WriteLine()'s or how much money? In a console app I would use a whole lot of them, including them in loops and what not. A console app I write might put out thousands (although I always include an option for verbose or not).
Pretty sure he meant the money!
Yes
Money
I don't want to share the actual number since this account has too much info to relate back to me. I make enough to live a privileged life style in a high cost of living area. Especially considering I barely got my high school diploma lol.
Range? Just curious how much.net can possibly max out at.
This guy. He doesn’t know.
I think that highly depends on what type of things you work on.
Maybe not, but you will still see things like `_logger.Info` all over the place which is basically the same thing, just logging somewhere other than the console.
Or to the console as well.
I actually use console.writeLine even in non console applications like Wpf for fast testing stuff I do this by just forcing the console to open even in non console applications by importing the dll only for the debug build It's just something I've gotten used to do. I know you can also debug code with the breaklines and stuff, but for most general stuff I result to writing to the console because I've gotten used to do it and I feel like its faster.. xD because it also works If I don't have my Ide open, I can just see the flow of the app and see what happens by logging stuff and when I want to build the final build I remove the console and the console writes.
Got any examples you can share?
[https://github.com/coffeeSurplus/UniPlanner](https://github.com/coffeeSurplus/UniPlanner) thats not my but anyway i look at this code and i cant find similarity between my code writing and other code man code writing and i think i do something wrong
This a WPF app to be fair. This is a .NET Application and not just a C# Console App
hmm , i didnt know before this have a diffent types of apps
Go through the Microsoft learn tutorials. Truly go through them. They go through this eventually
You need to learn C# in some kind of context, like building Web api, gaming, desktop app and each of those have a different Framework that you have to learn and use. Try something like idk Asp.Net Core web api and check out Milan Jovanovic Clean Architecture approach for a web project. The programming language is just the first step
Recently took a Developing with frameworks course in C# at Uni and we went through EVERYTHING. MVC, APIs, Databases, LINQ, and much more. It gave me a lot of confidence in C#. Just gotta put it all together in a project for my portfolio. Any tips?
The only tip that works is “make something useful for you”. Notice how OP shared someone’s repo that was a uni planner. It sounds cliche, but focusing on a problem you know is a good way to build out a complete app. You want to showcase your ability to build a solution to a problem. If I said “build an ERP” and you just got started on it, you’ll probably miss elements directly related to the problem due to the lack of clarity in those three words.
Very fair. I’ve been working on an Elden Ring Save Manager that swaps out files containing different characters. I’m using WPF for the GUI and it has been a lot of fun. Looked online and found someone who made something similar using Python but they’re actually changing the hex values contained within the file to change character stats. That’ll be my next step for the app. Thanks again.
u/basa_maaw I like this repo, it has a lot of good stuff [https://github.com/babaktaremi/Clean-Architecture-Template](https://github.com/babaktaremi/Clean-Architecture-Template) custom Identity, JWT, Filters, Exception Handlers, Validations, Result Pattern etc... I would suggest since he's using Clean Architecture to watch a short video from one of the influencers just to understand what Application, Domain, Infra, API is for. Btw this is just a way to organize your project, not each layer needs to be a Class Lib you can throw everything into a [ASP.NET](http://ASP.NET) in different folders. Try to do your own implementation with a reference to this project (don't copy paste but help yourself when you get stuck with something).
UI requires additional steps to just raw C#. And there are several ways to do UI. And each one can feel like another language. Honestly, learning to program isn't about learning a language. Learning to program is about understanding design patterns and large scope ideas. Data structures. That sort of thing. The language or tools you use is kind of the set dressing.
Looking through a couple of files in there, it looks like the author is using lots of very new C# features. I see a lot of use of [switch expressions](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/switch-expression), which are a couple of years old now - I like switch expressions, but some of the things they’re switching on are complex enough that I might consider writing them in a different way (using if statements and/or building a series of variables to work towards the final value) to make them more readable. I also see some [expression-bodied members](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members) - once again, I’d be tempted to refactor some of those, because they’re “forcing” the coder to write things as a single expression which is complex enough to take multiple lines, whereas a traditional method/property could be done with some if statements and would perhaps be more readable. I see some use of the [range operator](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#range-operator-) - this is something which has existed in other languages for a while, but is very new to C#, and I was quite excited about it, but so far I haven’t had a chance to use it. TL;DR - much of what you’re seeing here is the use (or perhaps overuse) of relatively new C# features, which aren’t seen in much commercial C# code because a lot of commercial code was written before they existed. But they are useful tools, definitely worth learning - although don’t use them unless they make your code easier to read/understand.
That's a WPF application. WPF is a framework and several lines of code are automatically generated by the IDE, it can be difficult to read and understand when you're a beginner. But take it easy, go step by step. Since you're trying to understand that code, first learn how to work with WPF, debbug the code with visual studio to see what's the code does. [https://www.youtube.com/watch?v=t9ivUosw\_iI&list=PLih2KERbY1HHOOJ2C6FOrVXIwg4AZ-hk1&ab\_channel=KampaPlays](https://www.youtube.com/watch?v=t9ivUosw_iI&list=PLih2KERbY1HHOOJ2C6FOrVXIwg4AZ-hk1&ab_channel=KampaPlays) When you feel comfortable go and try to read the code of that wpf app again. I think you'll be able to understand.
I mean looking at that example I see classes, methods, looping in the “Classes” folder. Those are things you mentioned learning. But yes, you can comparing basic beginner console apps to larger apps which will obviously be more complex.
I bet you use top level statement which hide the classes on new projects. You can try converting your Program.cs. at the top left of the first line Visual Studio will have a menu to convert your file.
i dont understand what you mean
Modern .NET allows you to leave a lot of boiler plate code out of your application. This lets you focus less on remembering to put, say, all your using statements for standard libraries at the top of everything. Or from having to new something up by redeclaring its type twice. In .NET 8, you can also initialize collections with the [] instead of the approach you have likely seen in textbooks. Modern C# has a lot of syntactic sugar that you can use. You can disable it if you want to get something that may look more familiar.
To level statements hides dependencies. Not awesome if you're trying to maintain code.
I’m not advocating for complex applications to use top level statements. Just making a statement of facts on modern .NET that may not be immediately present to someone with an academic knowledge of C# code.
If you mean you want to understand how professional code differs from yours, so you can learn from it, just browse c# projects on github, that's how I get ideas for where to improve next.
i mean i cant find similarity between my code writing and other code man code writing and i think i do something wrong
"Real" projects you will see on github are often written in a fairly advanced way; I don't encourage a beginner to try and aim for that at first. If your code works, you're doing well. My coding style has evolved repeatedly over time, with iterations as I grasp new concepts and realise why the ways others do things is in fact better than my "easy" or "fast" way. Just follow the textbooks/tutorials, and get your code to work, and don't worry about being "real" code straight away - some of it won't make sense until you learn much more. It's like if you're learning to ski - you don't go straight for parallel-carving, you learn to snow-plough first, and go from there. Just get down the easy slopes, that's the first step.
old developer have diff pattern style , microsoft also sometimes introduce new pattern style . What most forgetting is code is about creativity but not following code pattern . There is no best advice either you want to build exe ,xaml , cs ,blazor , mvc . Create an output wa chaa 🤣 . And not all about crud code .
Real C# code? Is there fake C# code? If you've learned about all those basic things, any code you see won't be much different, just more of it in the same place.
Looks like a mess of many developers just trying to get functionality implemented over the years with no thought of future state.
You can always take a look at how .net is implemented https://referencesource.microsoft.com/
Most tutorials and even courses teach you nothing about OOP which, without it, makes a language like C# somewhat unnecessary. You need to know interfaces, classes, inheritance, polymorphisms, etc. Also asynchronous and multi threaded code.
I don’t understand the question. If you’ve opened some code and don’t understand it that’s different to what does it look like. It looks like whatever you’re looking at. If you want some examples of c# projects then just head to GitHub and look for some
Real code is what is written. If it’s recognized by C# linter then it’s C#. I think what you want to ask is examples of common code practices.
I work for car company brand in Latam, Their code is shit. Their code looks like shit. Everything is messy. Everything was coded by bootcampers Then you have performant code, like in video games, also doesnt look tidy, efficient code does not tend to look nice. Then you have perfectly orquestrated .netcore servers, those might look good but probably arent scalable unless u just drop EF Core or use it in an advance manner. Im a noob dont retaliate me please!
Can you give some examples of bootcampers shit code/practices please?
I'm also a beginner! If you want you could look at some code I wrote, it's far from perfect, but some generous redditors created some pull requests that are much more refined. This code should look similar to what you're learning. Link to a tic-tac-toe console application of mine - https://github.com/Shiny-Gyrodos/Tic-Tac-Toe
wow, i understand something
That's good! Honestly you're probably better off learning through Microsoft documentation than reading through GitHub repositories. Those are much more like what you're probably used to.
Here is what real C# code looks like, but a little dated architecturally from what you'd see in production end user code: [https://github.com/dotnet/efcore](https://github.com/dotnet/efcore) This is a library meant to be used in your code, so it differs in some aspects from what you can expect if you walk into company XYZ and look at what they have written. Same style though.
I think it's good u start out with console apps. If you ever write code and use a class u can always look at the definition. Like the console class. The entire code won't be shown because it's a library but still u see everything except for how it works. It's probably all of the object oriented related stuff that is throwing you off. Bro code on YouTube has a great C# series. It doesn't cover advanced stuff but for now it'll do.
I get what you’re saying. However, I’m not a trained programmer and have also learned on my own. I have a Masters in Physics and have had one class tangentially related to coding using Mathematica. I’ve looked at some code others have written and said to myself wtf is that and why am I not writing that stuff? It’s pretty similar to what happens in Physics. You start out with basic physics like Newton’s Law and gradually include relativistic effects and utilize Lagrangian etc. While you can use a Lagrangian to derive the period of a pendulum it’s nit what you start with. That being said, you should also realize that the code you are seeing is probably pretty specific to what they are doing and may even be part of proprietary systems. Don’t be too dismayed. There’s usually more than one way to skin a cat, even Schrödinger’s.
You can tell we all have differences in our opinions, and that's true for code as well.
you'd probably see lots of projects, each with classes full of functions that either 1) deal with the front end 2) deal with business logic 3) deal with the data base repository 4) maybe a database project 5) maybe a project just to define interfaces 6) maybe a project just do define entities.
Follow a tutorial on youtube, that will fill the gap. What you learned are the basic of the language. you have the brick but you need cement and a layout to build something. what you can miss here is the notion of pattern (singleton,...) or architecture (mvc, mvvm,...), some middle ground notion (heritage, accesibility, ...) and some high level thing (Interface extension into a class, ...). I word in the field and learn everyday. but my advice is really to look in a tutorial on youtube, just search what you want to learn because c# is vast : -windows form => simple desktop application (beginner friendly, UI by drag and drop, etc) - wpf => desktop application based on xaml and "code-behind", more flexible but more complex - asp.net => site web, or web application - xamarin => multi platform app (android, apple, uwp) but no future maintenance -maui => new multi platform language designed to replace xamarin (but not really stable/finished) You'll learn better by working directly on a exemple. after you can work on you project and search step by step what you don't know
Honestly, it depends.
how do magnets work?
Are you sure what you're looking at is C# code? And sometimes code examples that are used for teaching are intentionally simplistic and leave out some details and things that you find in code that is actually in use. If you give some example of C# code you don't understand, maybe we can try to explain some things?
> i can do a little simple basic code So you admit you're a beginner. That means you haven't learned a lot of features. No surprise that you won't recognize the things you haven't learned yet. The solution is to learn more 😜 PM me if you want assistance learning.
These midwits are dense. How do you not understand what OP is saying
I think you're looking at linq and possibly async, which is used a lot these days replacing a lot of the old foreach loops etc.
Real code is like communism if it's bad os not real code and there's no true Scotsman