These are all the good options I came up with. I prefer option 2.

                       var option1 = list.GroupBy(orderDetail => new { orderDetail.OrderNumber, orderDetail.ItemNumber, orderDetail.LineNumber })
                .Select(orderDetailGrouped => new OrderDetail(orderDetailGrouped.First(), orderDetailGrouped.Sum(i => i.Quantity)));

var option2 = list.GroupBy(orderDetail => new { orderDetail.OrderNumber, orderDetail.ItemNumber, orderDetail.LineNumber })
                .Select(orderDetailGrouped =>
                {
                    var orderDetail = orderDetailGrouped.First();
                    orderDetail.Quantity = orderDetailGrouped.Sum(i => i.Quantity);
                    return orderDetail;
                });

var option3 = list.GroupBy(orderDetail => new { orderDetail.OrderNumber, orderDetail.ItemNumber, orderDetail.LineNumber })
             .Select(orderDetailGrouped => new OrderDetail
             {
                 OrderNumber = orderDetailGrouped.Key.OrderNumber,
                 ItemNumber =orderDetailGrouped.Key.ItemNumber,
                 LineNumber = orderDetailGrouped.Key.LineNumber,
                 Quantity = orderDetailGrouped.Sum(i => i.Quantity) 
            });
             
var option4 = list.GroupBy(orderDetail => new { orderDetail.OrderNumber, orderDetail.ItemNumber, orderDetail.LineNumber })
                .Select(orderDetailGrouped => new OrderDetail
                {                                       
                    OrderNumber = orderDetailGrouped.First().OrderNumber,
                    ItemNumber = orderDetailGrouped.First().ItemNumber,
                    LineNumber = orderDetailGrouped.First().LineNumber,
                    Quantity = orderDetailGrouped.Sum(s => s.Quantity)
                }) ;

I was tasked to group some data that had duplicate keys. The data was good as it was line items that came in as partial records. This resulted in some Dictionary Add row logic to fail. Working with a colleague we came up with a IEnumerable GroupBy extension method that I have found very interesting, useful, and something I don’t want to forget so I’m posting it here.

    internal class Program
    {
        static void Main(string[] args)
        {
            var list = new List<OrderDetail>
            {
                new OrderDetail { OrderNumber = "1", ItemNumber = "1", LineNumber = 1, Quantity = 5 },
                new OrderDetail { OrderNumber = "1", ItemNumber = "1", LineNumber = 1, Quantity = 5 },
                new OrderDetail { OrderNumber = "2", ItemNumber = "1", LineNumber = 1, Quantity = 5 },
                new OrderDetail { OrderNumber = "2", ItemNumber = "1", LineNumber = 1, Quantity = 5 },
                new OrderDetail { OrderNumber = "3", ItemNumber = "1", LineNumber = 1, Quantity = 5 },
                new OrderDetail { OrderNumber = "3", ItemNumber = "2", LineNumber = 1, Quantity = 5 },
            };
            var summary = list.ToOrderDetailGrouped();
        }
    }
    internal class OrderDetail
    {
        public OrderDetail()
        {

        }

        public OrderDetail(OrderDetail orderDetail, int quantity) 
        {
            OrderNumber = orderDetail.OrderNumber;
            ItemNumber = orderDetail.ItemNumber;
            LineNumber = orderDetail.LineNumber;
            Quantity = orderDetail.Quantity;
            Quantity = quantity;    
        }

        public string OrderNumber { get; set; }
        public string ItemNumber { get; set; }
        public int LineNumber { get; set; }
        public int Quantity { get; set; }
    }
    static class ExtensionMethods
    {
        public static IEnumerable<OrderDetail> ToOrderDetailGrouped(this IEnumerable<OrderDetail> items)
        {
            return items.GroupBy(orderDetail => new { orderDetail.OrderNumber, orderDetail.ItemNumber, orderDetail.LineNumber })
                .Select(orderDetailGrouped => new OrderDetail(orderDetailGrouped.First(),
                orderDetailGrouped.Sum(i => i.Quantity)));
        }
    }

Exceptions and Errors are the same things. Somewhere in software history, someone came up with the phrase “Exceptions are exceptional”. That sounds catchy but it doesn’t translate to Exceptions and Errors. If you go that route then who decides what is Exceptional? It is very subjective because an error for one context could be exceptional to one and not to another. Exceptional and Exception are very different words. Someone apparently thought the catchy phrase enforces the idea that there is a difference.

They are the same thing. I’m not a Java developer and I realize it has different classes for each but in the .NET world they are the same thing. The preferred error handling framework in .NET is the Exception class. It doesn’t care what you want to call it, an error or an exception. Nor does it care if it is exceptional or not. It is just a vehicle for communicating error information. You can communicate the severity of an error by creating and using classes that inherit from Exception.

To clarify, I’m speaking about the .NET library level, not the HTTP API level. I fully agree with the majority that data validation should not be considered an exception. Data validation should be handled before you get to the library level. There are many libraries available to make data validation cleaner and easier to use. Note that underneath, those libraries are throwing errors.

The Source of my information is here:

Cwalina, K., Abrams, B. F., Barton, J., Icaza, M. de, & Hejlsberg, A. (2020). Framework design guidelines: Conventions, idioms, and patterns for reusable .net libraries. Addison-Wesley.

Error handling seems to be controversial among developers.  I have found many styles in my career and believe there are best practices that will be beneficial. 

First, handle all your errors the same way.  Don’t have different logic for different errors.  I find throwing Exceptions to be the preferred method.  You are able to create custom Exceptions and add additional information that will help you in debugging and triaging issues.  The alternate method of returning error codes is dependent on the programmer checking for the error.  Throwing exceptions on the other hand will always be noticed unless the programmer swallows the Exception in a catch.

Handling errors the same way makes reading code easier. It’s clearer if everything is in the try-catch versus a bunch of if statements inside the try and then the other errors in the catch statements. It also separates the normal logic of the code away from the error handling code. .Net has a perfectly good Exceptions framework that supports custom Exceptions for whatever your needs are. There is no need to introduce something else that is not part of the try-catch framework. Overall it is a cleaner way of coding.

Having an error code in the Exception can be helpful as well as you can make your custom Exceptions more robust and reusable.  You can make your custom Exception generic enough as a category like Bad Data and then provide additional information in the error code such as what system or business logic the Exception occurred in.  You could also customize your custom Exceptions to a particular application, system, or service.  Overall, a custom Exception that is customized for a particular category and has an error code can be very reusable and can provide all the useful information that you need.

Although I haven’t successfully coded nor come across an application that does it, handling exceptions at the top of the stack seems to be the best way to process them. 

You really cannot discuss error handling without considering Logging.  Logging does create a log of noise in code as well as a lot of try catches.  It seems best to collect Exception where needed but to log them at the top.  If you do log at multiple levels in the stack I have found that you can provide a IsLogged property to an exception that is set once the Exception is logged and that way you do not have to log it again.  Also, not everything needs to be logged in production.  Use log levels and be very picky as to what you log as an Error level versus the other options.  And the Critical level really should only be used for an application wide, urgent Exception.

Sample code of Local Functions https://github.com/rhammonds/LocalFunctionSamples

I like Local Functions for the most part but every developer has different tastes. We all tend to function differently as well. I regularly use the drop-downs at the top of the screen to select classes and methods and it is cumbersome to see so many private functions. Also, many times we write logic or helper methods that are only helpful in one method.

And there are those who are fine with methods that have 100s of lines of code that I find difficult to read. There are those who see no issue in writing complex, multi-level if/else statements, which for me is so painful.

I prefer reading straightforward code, like a bullet list of steps. I believe local functions can help with this. They help break up complexity in a method without adding a bunch of private methods, which you don’t really want any other code to share. Methods are easy to understand when they are written such that they do one thing even if it is a group of related steps.

The main benefits of Local functions are really that you don’t have to write a private method, you can keep the function non-shareable and related methods are kept together. An example of related code may also be some code that reiterates and calls another method or piece of logic that is only used in the code.

It could also help if you are refactoring a very long method. You could slowly break out logic into smaller functions that you can later move around to something more object-oriented.

Now ideally, code should be OO and not procedural. I find it difficult to write all code in OO style, a lot of developers do not like it when I do that. Much of code is just passing data to other systems or applying business logic and OO-style is not always applicable or easy. Anyways, when you find yourself writhing procedural code in .NET, consider using local functions.

1. Coding style feature
   1. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/local-functions
   2. Pretty much follows the same rules as methods.
   3. Useful for long methods.  Not a panacea.  Just another alternative.
2. C# Version
   1. Introduced in C#7
   2. Static added in C#8
   3. Attributes added in C#9
3. Benefits
   1. Although it’s subjective and everyone differs, it can make code cleaner to read.
   2. Again it’s subject, it can write the language to be more direct without all the distracting details.
   3. Can reduce the need for commenting and using regions
   4. Complex code can be written as a method with a descriptive name
   5. They also make it impossible for another developer to mistakenly call the method directly from elsewhere in the class or struct.
   6. Reduces the need for private functions
   7. Some memory improvements versus Lambda expressions
   8. Improves iterator and Task methods exception handling
4. Problems LF solves
   1. Methods with a lot of comments
   2. Class with several one-off private methods
   3. Long Methods
   4. Methods with a lot of Sanitizing/validation logic
   5. Error handling in iterators and Task methods
5. Disadvantage
   1. It can lead to code duplication
   2. Doesn’t resolve long methods
   3. Might be overkill in small methods

I came across code where I needed to populate properties in a class dynamically, in a loop.  It is pretty straight forward if the type is int, string, date, etc.  But when it is an enum, isn’t so easy.  I was able to find a solution using the Enum.Parse function.  Here is some sample code:

    enum AnimalType
    {
        Dog,
        Cat,
        Bird
    }
    class Animal
    {
        public AnimalType AnimalType { get; set; }
    }
    class Program
    {
        static void Main(string[] args)
        {
            object target = new Animal ();
            var type = target.GetType();

            foreach (var p in type.GetProperties())
            {
                if (p.PropertyType.BaseType == typeof(Enum))
                {
                    var propType = p.PropertyType;
                    
                    try
                    {
                        var e = Enum.Parse(propType, "Dog");
                        p.SetValue(target, e);
                    }
                    finally
                    {
                    } 
                }
            }
        }
    }

This is a follow up to my previous article. Tends to be a recurring issue. Developers seem to follow existing patterns well and sometimes we tend start patterns inadvertently that are not ideal. One thing I see is creating a new .NET project just for organizing code. Multiple projects in .NET are best for how you plan to deploy your code. Namespaces and solution folders are a better choice for organizing code. For example, here are some good reasons for a project in .NET.

Reason to create a project in .NET

1. You want to deploy it to a different server than other code. Breaking your web site code from you web service code is an example.
2. You want to share your code with different client app code. Breaking your business layer out to be reused in multiple web services is an example.
3. You want to version your code separately from other code. Or you have code that rarely changes.
4. You want to load and unload your code dynamically.
5. You don’t always want the code deployed with other code.
6. It may be that your libraries are too large, and you want to have a few smaller libraries instead.
7. You want to limit what is referenced in your library, reducing the total output to the bin.
8. You want to encapsulate the implementation. For example, maybe you don’t want your business layer project to reference the data access such as SQL Server.
9. For securing code. This is useful if you want to secure code from just anyone accessing it.

Organizing code

When designing projects, be sure to weight the benefits of breaking your code up into projects by layers and types and even further by domain. Ideally, you want things to be decoupled and plug-and-play like so that it is easy to move them around. Putting your business layer, data access layer and types into the same library is not a bad option for most scenarios. There really isn’t a lot of gain with sharing types across business domains. Breaking your data access out into separate libraries doesn’t really benefit you much (unless you are doing microservices or something similar).

This was a good introduction into GitHub on Microsoft Virtual Academy.  The course name is GitHub for Windows Users

https://mva.microsoft.com/en-US/training-courses/github-for-windows-users-16749?l=Tt7XrFR9C_8906218963

Command line Cheatsheet

Click to access github-git-cheat-sheet.pdf

Good documentation

https://git-scm.com/

Good information on getting involved in open resource

http://www.hanselman.com/blog/GetInvolvedInOpenSourceTodayHowToContributeAPatchToAGitHubHostedOpenSourceProjectLikeCode52.aspx

Soft Skills & Leadership

• Soft Skills: The software developer’s life manual, by John Sonmez
• The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni

Software Architecture

• Just Enough Software Architecture – A Risk Driven Approach, by George Fairbanks
• Designing Software Architectures: A Practical Approach, by Rick Kazeman
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design, by Robert Martin
• Documenting Software Architectures: Views and Beyond, by Paul Clements
• Software Architecture in Practice, by Len Bass
• Patterns of Enterprise Application Architecture, by Martin Fowler
• Software Architecture for Developers, by Simon Brown

Software Design

• Refactoring: Improving the Design of Existing Code, by Martin Fowler and others
• Refactoring to Patterns, by Joshua Kerievsky
• Pattern-Oriented Software Architecture, multiple volumes, by Frank Buschmann
• Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma
• The Clean Coder: A Code of Conduct for Professional Programmers, by Robert Martin
• Code Complete: A Practical Handbook of Software Construction, by Steve McConnell
• Agile Principles, Patterns, and Practices in C#, by Robert Martin
• Clean Code: A Handbook of Agile Software Craftsmanship, by Robert Martin

SDLC

• Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, by Dean Leffingwell

Language Specific

ASP.NET MVC

• Professional ASP.NET MVC 5, by Jon Galloway
• Pro ASP.NET MVC 5, by Adam Freeman

WCF

• Programming WCF Services, by Michael Montgomery

C#, .NET

• C# 7.0 In a Nutshell, multiple version of C#, by Joseph Albahari
• Pro Asynchronous Programming with .NET, by Richard Blewett
• Dependency Injection in .NET, by Mark Seemann

Javascript

• Secrets of the JavaScript Ninja, by John Resig
• Angular 2 Development with TypeScript, by Yakov Fain

SQL Server

• SQL Server Internals, by Kalen Delaney

Training

• Plural Sight
• Safari Books Online

Blogs

• Morning Dew https://www.alvinashcraft.com/
• Morning Brew http://blog.cwa.me.uk/

Other

• Code Wars http://www.codewars.com/dashboard

Note

When it comes to reading books, I’m terrible at it.  I rarely finish a book.  I usually get through a third of a book and I’m distracted by another book and start it.  It’s also difficult for me to remember what I read and technical things take me longer to comprehend so I try reading at a slower pace to make things stick better.  All that being said, I do think I can recognize a good book.  I am more attracted to books that I believe will stand the test of time or at least be useful for a few years.  And I tend to prefer good authors and experts in the field.