Reddit mentions of Windows Forms Programming in C#

Ukratko, WPF aplikaciju praviš deklarativnim UI-jem u XML-u i kodom iza koji reaguje na ivente, radi pos'o, itd.. Windows Form aplikacija je sasvim drugi frejmvork sa sopstvenim apstrakcijama i programskim modelom, sve se dešava u kodu. Dve različite .NET UI tehnologije sa istim ciljem, otpr. kao Swing i AWT u Java svetu (ko se seća ovog drugog, nemam pojma da li se to još igde koristi).

Ne postoji jako dobar razlog da danas koristiš Windows Forms, osim ako to nisi koristio do sada i znaš mu sve fore i fazone, a rokovi su pretanki da bi osvajao u procesu novu tehnologiju.

Edit: Ovo je po verovatno najbolja WPF knjiga - WPF Unleashed, tj. bar je bila do pre nekoliko godina, a ovo pamtim kao najbolju Windows Forms knjigu - Windows Forms Programming.

Here is how I go about trying to become an "expert":

In short, if you have ever read Alan Perlis's "Epigrams on Programming", most of the things there are pithy explanations of what I'm about to say. Probably my favorite epigram as it relates to being a "language lawyer" is:

​

>10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

​

This is critical, because, as most here will tell you, it's nearly impossible to keep every aspect of C# - both how and why - in your head at all times.

​

That said, at one point I was an awful engineer. Let's get into how I became a significantly better engineer.

• ReSharper
  
  • I would diligently fix everything ReSharper would warn me about. Even typos. You might think this is dumb, but as a 12 year old kid, I would sit in IRC chat with the founder of Dinkum Software, Tom Campbell, and he would tell stories about how many places he's consulted for where the engineers would ignore compiler warnings.
    
• Mastering for loop, foreach loop, while loop, do-while loop
  
  • I practiced a lot of problems from books like Deitel&Deitel, but also read books like Code Complete which talked about off-by-one errors, as well as research by Whitehead et al on bug fix patterns. If you read the research, you'll see that most bugs are caused by relatively simple mistakes. What's also interesting is the same developers repeat the same mistakes. Meaning, if a developer has a bug because they used for loop instead of foreach to iterate over an IEnumerable, chances are they have written code elsewhere in your code base with the same mistake. The same goes for not closing database connections and not using using statements to automatically dispose of external resources (like database connections).
    
• Avoiding Anti-Patterns
  
  • Was told in college, by an engineer from Naughty Dog Software, who worked on Crash Bandicoot and other great games, to avoid using singletons, because you can never predict when you might actually need more than one of something. Gosh, looking back, this simple advice was so hard to follow at the time.
    
  • I read books on the subject of Anti-Patterns, such as Eric Allen's Bug Patterns in Java
    
  • I read blog posts about anti-patterns, and would discuss them with friends. It may sound weird, but I did not want to ever be that engineer who was programming with their pants down and didn't realize it.
    
• LINQ
  
  • I spent a lot of time writing SQL and "Thinking in sets".
    
  • But I also benefited a lot from listening to Bart De Smet talk about The Essence of LINQ and the "MinLINQ" talk he gave on Channel 9: https://channel9.msdn.com/Shows/Going+Deep/Bart-De-Smet-MinLINQ-The-Essence-of-LINQ - at the time, I had been reading blog posts about anamorphisms, catamorphisms, and isomorphisms written by Haskell programmers and most of the stuff flew right over my head, but most of what Bart discussed here deeply resonated with me.
    
• Parallel LINQ
  
  • After digesting Bart De Smet's Essence of LINQ talk, I started to parallelize code at work by figuring out what the serializable sequences of business logic were, and splitting IEnumerable's of my entities via things like candidates and companies, and then passing that down to a timesheet processing engine I wrote.
    
• Task Parallel Library
  
  • This is slightly more complicated than Parallel LINQ, especially if you have not done much concurrent programming before.
    
  • One of the first things I did was search for common TPL bugs on Stack Overflow, via searching for "tpl deadlock asp.net" on Google. Boom. Bunch of blog posts came up written by consultants teaching me some things that I probably learned in my computer science program, probably got right on a test at some point, but forgot about.
    
  • One of the most basic things you can do when writing concurrent code is to know if the libraries you are using are thread-safe. Many libraries will say as much, especially those written by Microsoft. For example, Entity Framework DbContext is not thread safe. If you're going to start using concurrent code, probably the hardest thing to get to grips with is how to safely call non-thread-safe code in a thread-safe manner, or how to look for alternatives that are 100% thread-safe.
    
• Micro-benchmarking
  
  • Learn how to benchmark code. Even if it is just using StopWatch and Xunit to start out.
    
  • Try implementing things two different ways that on the surface seem identical, but are syntactically different, and then figure out why one is slower or faster than the other. If you can't figure out why, ask someone, and then try to generalize their answers so you can apply those lessons learned in other areas of performance tuning.
    
  • Eventually, graduate to newer tools like xunit-performance and benchmark.net
    
• Learn every step of the build pipeline
  
  • I grew up with Visual Basic 6, so I was somewhat accustomed to dragging and dropping objects to create user interfaces, and doing "rapid application development" (RAD). While my first employer helped me break this habit, it wasn't until I read Chris Sells' Windows Forms Programming in C# introduction in chapter 1, "WinForms From Scratch", where he built things from the ground-up, that I started to believe it was even possible to pull back the curtain of such vastly complex systems. In this book, he uses the most basic feature, the c# compiler and a text editor, and doesn't even use *.sln files or *.csproj files. Then he dives into configuration settings XML-first and then shows you the Visual Studio GUI for it after the fact.-- I apologize to those of you laughing at me reading this, but you have to realize, growing up, walking to Barnes & Noble as a teenager and sitting on the floor hoping to one day learn enough to do this cool programming stuff professionally, I had glanced through thousands of books, and this "hands on" ground-up approach was nothing short of revolutionary.
    
  • If you're talking to a database, learn a database migration framework. I recommend FluentMigrator, but I've also used Chuck Norris' RoundhousE and Flyway.
    
  • Learn how to configure and use a build server like TeamCity
    
  • Learn how to configure and use a deployment server like Octopus Deploy
    
• Code as Data, Data as Code duality
  
  • I recommend learning Lisp to deeply understand expression trees, but understanding the trade-offs in storing code as data, and then Eval()-uating it on the fly (such as is done effectively when you call Entity Framework ToList()), can give you powerful new concepts to think about how to solve problems that otherwise wouldn't seem possible without piles and piles of code.
    
• Build a Technology Radar.
  
  • Data mine the crap out of NuGet. Look at what is popular and try to learn about half of those technologies. Chances are everyone commenting here is familiar with at least half of those libraries. Create a scorecard for yourself on a scale of 1-10 for each library on how familiar you are with those technologies.
    
    • Also, don't forget to be reasonable. If you're a computer game programmer, you can probably skip SQL specific libraries like Dapper and Entity Framework.
      
  • I have a radar on my GitHub which ranks various third party libraries and I try to take detailed notes (in private) about why one library is better than another. As an engineer, you'll be asked to solve the same problems over and over again. Figure out the best way and keep track of why it's the best, so you can know when to switch
    
• Testing and writing testable code
  
  • The best thing you can do here is to work with someone who is a master at writing tests.
    
  • The next best thing you can do is probably to learn the basics of writing really clean tests, such as Arrange-Act-Assert, Record-Replay, Mock Objects and Mocking Frameworks
    
  • Become familiar with what can be easily mocked, since it will determine how you choose to design a lot of your object models once you become "test-infected" and write tests as you write your code
    
  • Tools like AutoFixture for generating objects as part of your system under test
    
• Dependency Injection frameworks
  
  • Look at IoC Benchmarks by Daniel Palme. I have learned a lot about performance tuning C# applications by reading through the discussions of issues on this mailing list. Some very smart programmers contribute to this project.
    
  • Learn how you can use a DI framework to create singletons at the container-level, rather than using C# keywords like static.
    
• Combining DI frameworks, AutoFixture and your mocking library to write very concise tests.
  
  • Once you start to see the power of combining a few smaller frameworks, you will begin to appreciate why you don't need big "do everything" frameworks
    
• Generic Programming
  
  • Start off with doing basic generic programming, like strongly-typed collections.
    
  • Graduate to abstractions you might not normally think of, such as generic types that exist only as a "phantom type" to pacify another part of your system, such as a dependency injection framework
    
  • Graduate even further to generic expression trees - functions that return generic code-as-data
    
• I could add more, but I'm at the 10,000 character maximum