DEV Community: Sam Fields

Things you need to know as a developer - Clean Coding

Sam Fields — Tue, 26 Jan 2021 16:57:43 +0000

Introduction

In this post, I will cover the things I find most important to know about writing clean code and why we should strive to achieve it.

Why Clean Code?
Choosing the right tools
- The email regex example
Keep things separated
Code Metrics
Things to avoid
DRY Principle
Implement good standards
Self-documenting code

Clean Code

It's important to understand that besides the compiler, we as programmers should also be able to easily read our code and others as well. Badly written code can create a bad development environment for you and your team, it can increase the number of bugs in your code, decrease flexibility, and increase code complexity and redundancy, which all contribute to increased technical debt.

Why?

1. Reading code is harder than writing code!

Reading old code is hard, sometimes it might even happen that you can't read your own code you wrote 1 month ago.

2. "I will make this better later..."

If you are telling yourself that, then there's probably more than a 50% chance you won't do it ever.

3. Technical Debt

Badly written code creates technical debt, which is:

Costly for the company;
Cumbersome and boring for you to fix later.

4. I'm a lazy programmer

Although they say some of the best programmers are lazy, this should not apply for when you are writing your code. You can still be a lazy, good, creative, and fast programmer whilst writing clean code.

5. Clean code vs Development Speed

Some might say that the required extra care can cripple their development speed. I don't think these two things are incompatible; if you know and practice your code standards and clean code practices beforehand, when you go to code they will naturally arise without you even thinking about them.

Choosing the right tools

The first step for writing good code is having the right tools to do so. We should select the best tool for the job. This could be an IDE or programming approach to a problem. My favorite example is the validation of an email.

The email validation nightmare

The most common approach I see is the use of a regex for this task. The problem is that the regex required to do this is awful and completely fallible if done wrong.

Example of a possible email regex in C\

Example of an email regex in other languages

And depending on the language it could be totally unreadable. Check this website with the email regex for different languages. Just take a look at the Perl/Ruby implementation. 😱😱😱 What a nightmare!

An alternative for .NET developers

If you are working with ASP.NET there might be a better alternative. This to make the case of finding the right tool for the job you could use the:

System.ComponentModel.DataAnnotations
System.Net.Mail.MailAddress

All these strategies have advantages and disadvantages and we must select the one that works for our requirements and that doesn't create unnecessary complexity or a potential source of bugs.

If you want to go more in-depth about this email issue look at this StackOverflow question

Keep things separated

When dealing with a full-stack project it's a good idea to make sure that different code types are kept in different files. For instance, avoid having HTML, C#, and Javascript code in the same file (e.g., .cshtml files). Here are some reasons why:

In general separating your code will possibly allow for code highlighting and syntax verification, which makes for better readability and prematurely catches silly syntax errors. Although this might not be the case for every language and project.
When dealing with javascript, having the code in a separate file allows you to potentially cache the code and perform other optimizations like modification and compression, which might not happen if the code is on an HTML file.
Separating the code into different files will possibly promote the practice of separation of concerns and also make it reusable.

Code metrics

Nowadays we have several ways of measuring different code metrics that allow us to learn several properties about our code. Some metrics include:

Cyclomatic complexity
Maintainability Index
Depth of Inheritance
Class Coupling
Lines of code metrics

These metrics can be automatically measured from your IDE using built-in functionality or a plugin. For instance,

Visual Studio 2019 - Offers built-in capabilities for generating code metrics
Resharper for VS2019 - Offers continuous code quality analysis, code smell, and error detection, and standard enforcement.
Visual Studio Code - Offers different plugins well, check them out here

Another way of getting code metrics analysis would be static code analysis tools, e.g. the open-source tool SonarQube to perform static code analysis allowing you to detected bugs, code smells, and even security vulnerabilities. This can mainly be useful when added as a step in your CI/CD pipelines to ensure that standards and metrics are maintained.

Things to avoid when writing code

High Cyclomatic complexity

Cyclomatic complexity is a software metric used to indicate the complexity of a program.

High cyclomatic complexity is an indicator of complex and hard to follow code. It might be an indication, for instance of nested if-else statements and method calls. Try to avoid this when possible.

Zombie Code

This is code that you might find in your projects that are not being used at all or is deprecated but not properly identified as such. Over time this can amount to larger binaries, longer code to go through, and more testing required where it might not even be necessary. It can manifest in the form of unreferenced methods or functions or even blocks of commented code.

If you ever see this in your codebase, it might be a good idea to ask someone more knowledgeable about the project if it could be removed. Another strategy is to implement QA tasks in your projects to periodically tackle the technical debt of the code.

Excessive indentation and no whitespaces

The use of excessive indentation or the lack of it can create hard to follow code, sometimes the reader having to indent the code himself. Nowadays most IDEs offer some way of fixing indentation automatically and others even enforce and fix code standards. These standards can usually be customized for the developer's needs.

Long classes and methods

The rule of 7 is based on the idea that humans can only remember up to 7 things at a time. Therefore, if you create anything with more than 7 parameters it will be very difficult to manage and go through.

One thing I remember from university when studying processors is that they have something called registers and they come in a limited number. Putting it very simply and general:

For some architectures, when invoking a function, the processor uses those registers to hold those variables, because it makes the operation extremely fast. If the number of passing parameters exceeds the number of available registers then the processor needs to store the remaining parameters elsewhere, which leads to a lot more work and maybe small performance penalties.

Therefore I always try to keep the number of parameters to less than 7, usually 4 or 5.

This rule usually applies at:

The number of parameters in a method
The number of variables in a method
The number of methods in a class

Unnecessary comments

All I have to say about this is, avoid doing commentaries like this:

In my opinion, we should only add comments when:

On a property when we want to explain what it does in the given context and the name in itself is not enough.
To explain some obscure algorithm that performs a very specific thing that isn't clear given the context where it's found.
To justify a decision on why something was done a certain way and to avoid possible "corrections".

Poorly named data structures and variables

Poorly named variables and data structures can have a very significant negative impact on the readability of our code. In some cases, even a simple code snippet can become frustrating to decipher because of badly chosen variable names.

Another bad consequence of badly naming things is that it can misguide the reader to what the class, method, or variable are doing. This can lead to bad usage of the code and resulting in unexpected behavior.

In the second part of this post, I'll go into more detail on naming classes, variables, and much more.

Overly verbose names

That being said we should also try and avoid being too explicit on what a class or method is doing and avoid overly verbose names!

ValidatePaymentAndSendEventMessageToPipeline()
ValidateInputProcessDataAndReturnResult()

There's no reason why we need to be so descriptive about what's happening in those methods. Sure we can kind of guess what's happening just from the name, but we can probably also guess what's happening by looking at the code. There's no added advantage in being so descriptive. Something like this should be enough:

ValidatePayment()
ValidateAndProcessData()

And if it's not consider adding a //summary section above the method giving some further information about the method.

DRY principle´

The DRY principle stands for:

Don't Repeat Yourself.

As a developer this tells that we should try to:

Decrease the amount of unnecessary code in the codebase.
Decrease the number of lines of code and not have more of them.

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight" - Bill Gates

3.Try to detect patterns that are repeating in your code and refactor them into one cohesive code block shared by the entire code base, when applicable.

Self-documenting code

In general, the code should be self-documenting, meaning that for the most part, a developer should be able to understand what it's happening in there. And to make sure that happens we should make sure we write clean code! This is not to say we should have comments describing the code, but try to be clear with your code before adding commentary on it.

Conclusion

These things I've talked about here I believe to be for the most part of general application. Do you disagree on something? Please let everyone know your experience on the matter!

So happy to being back to writing! Almost after 5 months, I started a new job in London and I am still in the process of trying to move there! Quite an adventure that unfortunately didn't leave me with much time for writing. But I'm back :D

LINQ: Caveats and pitfalls

Sam Fields — Mon, 21 Sep 2020 16:31:57 +0000

In the third installment of the "Things you need to know as a C# developer" series, I want to look at some caveats and pitfalls of deferred execution in LINQ.

This concept can sometimes cause some confusion and can create performance problems and create super annoying bugs when misused.

This post expects that the reader has some working knowledge of LINQ. This post is a practical overview of how LINQ runs in the background and how it can affect your program. 😁

LINQ
Imediate Execution
Deferred Execution
- Deferred Streaming Execution
- Deferred Non-Streaming Execution
- What is query evaluation?
- Things that force query evaluation
- Comparing how deferred and imediate execution works
The dangers of deferred execution
Things to remember

LINQ

In the past, to access different data sources, we would require different API's to work with them:

Memory Data with generics and algorithms
Relational Data with ADO.NET and SQL
XML Data with XmlDocument
And many others

LINQ offers a consistent way of working with all the data sources referred above using a single interface. It allows us to write less and more expressive code, which is fantastic! :D

LINQ functionality is available when we include the "System.Linq" namespace in our code. Its usage comes in two flavors:

Extension method syntax

Query method syntax

These lines are called LINQ queries that can contain expressions that create more specific results. The queries can be evaluated immediately or at a later time to produce an output.

Execution types

LINQ methods or query operator methods exist in 3 flavors of execution: Immediate execution or deferred execution, which then classifies as (streaming or non-streaming). Let's now take a quick look at each of them.

Imediate execution

Immediate execution (IE) means that the LINQ method executes in the same line as you see it. A method that uses IE evaluates the LINQ query and produces a concrete result by accessing a data source or a memory location; this is a program flow that we all know.

Some LINQ methods that have immediate execution are:

.All()
.Any()
.Average()
.First()
.ToList()

Deferred execution

To defer something means to "put off (an action or event) to a later time; postpone".

Deferred execution means that no work happens (no data source is accessed) until we "force the LINQ query to be evaluated," creating a result to be "available" (I will make this clearer in a later section). For fun, I also like to call this type of execution one of the following terms:

"I will only do it if I have to" execution or;
"I will only do the bare amount of work possible" execution or;
"I will wait until the last moment to do it" execution or;
"I might not even do it" execution.

Deferred execution is available in C# by using the two keywords yield return. We will see an example of this in the next sections.

Some LINQ methods that use deferred execution:

.Where()
.Skip()
.Take()
.Select()
.OrderBy()

🔥 Hot Tip 🔥

As a rule of thumb, if the LINQ method returns an abstract type (e.g., IEnumerable), it's probably using deferred execution.

➡️ When in doubt, you can use this table as a reference.

Deferred Streaming Execution

Deferred streaming execution means that the method uses a process known as lazy evaluation when iterating through a collection; this means that only one element of the collection is read and used each time an iterator asks for a new element of the set. A method with this type of execution almost always returns in the form of an IEnumerable<T> or IOrderedEnumearble<T>.

Examples of these methods using deferred streaming execution in LINQ are:

.Where() - Used to create a filter over a collection.
.Skip() - Used to skip the first available N elements of a collection.
.Take() - Used to retrieve the first available N elements of a collection.

Deferred Non-Streaming Execution

On the other side, we have deferred non-streaming execution, which means that the method uses what is sometimes called "eager evaluation"; the first time an iterator goes through the collection, reading it entirely. The non-streaming execution might require temporary variables to store the original collection (e.g., when ordering a collection).

Examples of this type of execution in LINQ are:

.OrderBy()
.GroupBy()
.Join()

What is query evaluation?

So one question you might be asking is: What does it mean to "evaluate" a LINQ query that ultimately produces a result?

1 On a very, very general way, when an expression is created, for instance, something like this:

2 When the query evaluation happens, it gets converted into expression trees. Which can look something like this:

3 Then those expression trees get translated into other types of queries, e.g., LINQ query translated into a SQL Query when using LINQ with Entity Framework.

4 The translated queries are executed against their data sources, followed by creating the desired result objects using the results of those translated queries.

5 Creates a happy programmer because LINQ is awesome to use, and our code stays very clean. Clean code, Happy coder? 😅😁

Query evaluation can happen in the client-side (e.g., your program) or the server-side (e.g., in a database);

Things that force query evaluation

Enumerating with a foreach;

One of the things that force a deferred method to evaluate is iterating through the resulting collection from a LINQ operation. That happens, for instance, when we use a foreach loop to iterate through a collection:

Chaining to deferred extension methods a method that does not implement deferred execution

Another way of accomplishing the method to do work is to chain a query method operator that requires access to the data such as:

.ToList() - forces immediate query evaluation and returns a List *.First() - forces immediate query evaluation and returns the first entry of type T in the IEnumerable

Comparing how deferred and imediate execution works

One way of understanding what deferred execution does it to compare it against the immediate execution implementation of a method does the same thing. Next, I show two custom filter methods that perform the same task; one implements a method that uses
a deferred execution strategy and the other an immediate execution strategy.

Custom filter method using immediate execution

This implementation uses a temporary variable to hold the results, which increases the auxiliary space complexity of the method;
To return a result, the method must access the entire collection.

Custom filter method using deferred execution

This implementation doesn't use any temporary variables;
Once there's a match with the predicate, a result is immediately returned to the caller as it accesses the entire collection.
This is not apparent here but, the caller might not end up iterating through all the results. For instance, if a cancelation token is issued, a condition is met that stops the enumeration, or an exception is thrown. Which means we might avoid iterating throw the entire collection unnecessarily.

✔️ Just Do It! ✔️

I advise you to copy, edit and debug the snippet bellow step by step to see how the program flows and compare both execution types. This way, I assure you that you will understand how deferred execution works!

This next snippet shows you, with some funny dialog, at least that is what I was going for: deferred and immediate execution at work. Please run the code in➡️ this fiddle ⬅️ to see the comparison between both types of execution, or copy and run it locally.

Dangers with deferred execution

So, as with everything, there are good things, but there's also bad things, things that happen when we don't know what we are doing.
As this proverb says, "The road to hell is paved with good intentions." so yeah... Let's take a look at some things to be aware when using LINQ:

Deferred exception execution

Take a look at the following code snippet:

This piece of code is inside a try-catch block because we want to make sure our code handles an IEnumerable object that could potentially be null. (Ignore the fact that we could apply several other strategies here; this is to make a point with an easily understandable example).

I now ask: Which line of code throws an "ArgumentNullException" exception?

If you said line 14, then I'm sorry, but your program just crashed! If you told line 21, then you are correct! Why?

The .Where() method uses deferred execution, which means it evaluates the query to execute when a value is requested. In this example, the requested value is in line 21, which triggers the query evaluation and subsequently throwing an exception.

t => !valuesToRemove.All(x => x == t)

But notice that it stands inconveniently outside our try-catch block! Therefore because we are performing work outside the scope of the try-catch block, our code throws an exception, and the program crashes.

A sneaky and hazardous situation! But now you know to be aware of this.

Multiple enumerations

The performance problem

So deferred execution is great. IEnumerable is great. It saves us from unnecessary data fetches and processing time, but there's a bad side to all this flexibility. If the users don't know how to use it, they can unknowingly write bad code.

Sometimes, our code performs several method calls, passing the same parameter between those calls, or maybe we have a pipeline that's executing several computations on a particular dataset. There is a problem that can occur when one of those parameters is an IEnumerable. Take a look at the following code snippets that implement two pipelines that perform the same tasks.

Pipeline A

Pipeline B

Can you see what the problem between these two pipelines is?

Because of the use of methods that cause immediate execution between pipeline A, we are doing something called multiple enumerations the IEnumerable, which means that the data is retrieved numerous times from the data source.

If your data source is a List or any other source in memory, this is not a problem; if your data source is something like a file or a database, we can potentially come to face a significant performance problem.

As the size of the data returned by the data-source increases, the execution time increments very fast for the multiple enumerations scenario, but its constants for pipeline B were methods that only used deferred execution until the last step where the data is necessary.

In contrast, pipeline B deferred all execution inside the pipeline, which is the preferred solution. Although sometimes we might not be able to avoid it, and that's fine. The purpose should always be to have clean and performant code.

Please take at this complete [code snippet] where the pipelines are an analogy for a stack that spans several method calls (https://dotnetfiddle.net/rlcHoN); you will see that:

Pipeline without multiple enumerations takes approx. 0.001 ms to execute.
Pipeline with multiple enumerations takes approx. 4 ms to execute
As we increase the number of elements in the file, the processing time also increases. Now test this code against a database with millions of records, you see where this is going.

🔥 Hot Tip 🔥

A tool like Resharper can be a great option to warn you about multiple enumerations in your code.
Try to avoid query evaluation if possible unless there is some clear advantage not to do it;

The consistency problem

In this section, you will see why sometimes you might need to force query evaluation after fetching data from a data source.

As if the performance problem wasn't bad, I think this one is equally bad or worse.

Imagine that your data source is a database. If you have multiple enumerations, that results in numerous calls to the database to retrieve data at different moments in time. Can you think of anything that could happen to the database in between calls?

Well, if you are performing operations on a particular set of records, it could happen that in one of the calls to the data source will return different results because between requests, someone may have updated the data source!! Someone could perform an update to the same dataset you are working with, which results in you manipulating different datasets where you thought it was always the same. This unexpected consequence can create a very sneaky bug 🐞 to find.

✔️🧠 Remember

If you can't be sure that someone will perform an operation that will force query evaluation more than once, it might be a good idea to use .ToList() before sending the collection to another part of your code so to avoid these two situations.

🧠🤔 Things to remember:

A call to a method that uses IE can be wasteful because we might not even use the work it has done for us.
A call to a method that uses deferred execution does not do any work internally until it's required to "produce" a result, this means potentially saving resources and time on doing useless work.
Given a method using a deferred execution (streaming), the processing scenario would be:
- A value that matches a predicate is found.
- The method returns a value and yields (gives control) to the caller.
- The next time the caller asks for another value, the program will continue execution from where he exited the scope before, right after a yield statement (as shown in this the code snippet).
When the deferred execution method only looks at one element from the data source before yielding a result, we say it's a streaming deferred execution, e.g., the .Where() method.
When the deferred execution method looks at the entire data source before yielding a result, we say it's a non-streaming deferred execution, e.g., the.OrderBy() method.
We should usually avoid using the .ToList() method or any other methods that force query evaluation (or immediate execution) prematurely but at the same time, we should take into consideration it's dangers:
The IEnumerable interface is handy; we should use it carefully to avoid performance problems caused by multiple enumerations. In the worst-case scenarios, this could mean calling and querying our data source (e.g., a database) several times, wasting valuable time and network resources.
The use of the IEnumerable interface can bring immense flexibility and performance benefits to your codebase. Still, at the same time, if not designed correctly, it could introduce costly mistakes in both performance and data consistency.

I hope you found this post informative. If you have any doubts, knowledge you would like to share, or any questions, please put them bellow as the community members, and I will be glad to interact with you!

Algorithms Every Developer Should Know - Binary Search

Sam Fields — Tue, 15 Sep 2020 15:34:49 +0000

In this new series "Algorithms Every Developer Should Know", I'm going to explore the implementation of algorithms everyone should know (if you need them, otherwise it's fine) using C#. For the first post, we will take a look at Binary Search, a search algorithm used to find the position of a specific value in a sorted array.

Using an iterative or recursive approach, we can implement the binary search algorithm, and we'll take a look at both of them.

Binary Search Algorithm
- Definition
- Time Complexity
- Auxiliary Space
- Step by Step pseudo-code
- Edge Cases
Implementation of the Binary Search Algorithm using an iterative approach
Implementation of the Binary Search Algorithm using an iterative approach
Generic implementation of the binary search algorithm in C#
Explore the code

Binary Search Algorithm

Definition

Search a sorted array by repeatedly dividing the search interval in half. This algorithm is useful in finding the position of a specific value in a sorted array.

Time Complexity

O(logN)

Not going into detail but, but this tells us that for an array with N = 8, the output of logN is 3, which means we can split the array 3 times, so the number of steps (at most) to find the target value will be (3 + 1) = 4. Where 1 is the first attempt and also the best-case scenario in which the middle element of the array is our target value.

Auxiliary Space

O(1)

The constant space of 1 tells us that the algorithm does not require temporary additional memory allocations to do its work.

A step by step look at the algorithm

Starting with the middle element:

1. If the target value is equal to the middle element of the array, then return the index of the middle element -> [goto 3].
2. If not, then compare the middle element with the target value;
- 2.1 If the target value is greater than the number in the middle index, then pick the elements to the right of the middle index, and -> [goto 1].
- 2.2. If the target value is less than the number in the middle index, then pick the elements to the left of the middle index, and -> [goto 1].
3. Found a match, then {return the index}.
4. Did not found a match, then {return -1}.

Edge Cases

There are some edge cases we must be aware:

1. The element might not exist in the array

If the element does not exist in the array we must make sure that the search does not get out of bounds and consequently creating an exception because of it trying to access an invalid index.

2. The target value could be in the rightmost or left most side of the array

3. The target value could be the initial, middle element

4. Duplicate entries could exist in the array

Using this algorithm to deal with duplicates is not appropriate, but it will return the position for the first element that it finds.

Implementation of the Binary Search algorithm using an iterative approach

Implementation of the Binary Search algorithm using a recursive approach

I find this approach the most natural when I start to write this algorithm. It doesn't make it better or worse than the iterative version.

Generic implementation of the binary search algorithm in C#

This algorithm is not necessarily used to only sort integers or numbers. You can use it to sort anything as long you can provide a way for the computer to know how to classify different objects. To see that in action, you can see this fiddle.

For this, you can use different strategies:

The generic type you are using implements an IComparable and/or IEquatable.
Add parameter to the method that executes the algorithm and passes a IComparison parameter.
Add parameter to the method that executes the algorithm and passes a ICompararer parameter.

Explore the code

I have added the code in this fiddle, so you can test the variations and play with the code at will to make it easier to understand the concepts.

Things you need to know as a C# developer - Collections

Sam Fields — Mon, 14 Sep 2020 17:17:39 +0000

In this post, we will take a look at the main C# collections, summarize their main features, and quickly bring to attention some sneaky things about them.

Arrays
- Features of an array
Collections
- Common features of almost all collections
- Selecting the best collection for the job
Lists
- List add operations can be costly
- Example of an O(n) operation using RemoveAt(0) with a List
- Do not perform O(n) operations inside a loop!
- Sorted List
LinkedList
Dictionary and related types
- Features of a Dictionary
- Sorted Dictionary
Stack
Queue
HashSet
- The best solution for dealing with duplicates
- Comparison between Dictionary and HashSet
- SortedSet
Read-Only Collection
- Caution ReadOnlyDictionary it's not really read-only
Immutable Collections
Some examples of time complexity in collections

Arrays

An array is a reference type that contains a fixed-size list of elements that can be accessed using a positional index number. They are available through the System.Array namespace.

Features of an Array

Strongly typed
Useful when an array size can in known at design time.
No ability to add or remove elements.
Allows for multiple dimensions (array of an array)
Using an array might allow you to squeeze out a bit more performance with large datasets.
Two similar arrays are not equal when compared (arr1 == arr2) because they are reference types. The memory location is what's compared and not the content of the array.
To compare the content of the array, we can use the possibly expensive SequenceEqual() method.
When assigning array X to array Y, the equality of (x == y) equates to true.
An array occupies a single continuous block of memory.

Collections

A collection is a class that provides in-memory management of groups of items; by providing methods for adding, removing, or finding things in the collection. The items can be similar (strongly typed) or different from each other.

There are four main types of collections: generic collections and non-generic collections, concurrent and immutable. These are the following namespaces:

Not Strongly typed & Strongly typed System.Collections &(System.Collections.Generic)
Concurrent (System.Collections.Concurrent)
Immutable (System.Collections.Immutable)

Common features of almost all collections

Used when the number of elements is unknown at design time, or it's required to have the ability to add and remove elements.
The ability to iterate through the collection (implements the IEnumerable interface).
A method to copy it's elements to an array with CopyTo().
Provide information about the capacity of the collection and the number of elements currently in it.
They are 0-indexed, meaning the first element is always at [0].
Two similar collections are not equal when comparing (arrayX == arrayZ) because they are reference types. The memory location (reference) of the object is what's compared and not the content of the collection.

Selecting the best collection for the job

In general, avoid using non-generic collections. I recommend using the generic and concurrent versions of the collections because of their greater type safety and other improvements.

To learn how to choose the appropriate collection, check https://docs.microsoft.com/en-us/dotnet/standard/collections/#choose-a-collection and https://docs.microsoft.com/en-us/dotnet/standard/collections/selecting-a-collection-class.

Taking a look at the .NET collections

Next, I will quickly introduce the properties and make some observations of some of the .NET collections.

Lists

Occupies a single continuous block of memory.
Optimized for fast lookups
To look up an element using the List .[] index access is an O(1) operation.
To lookup an element using a method like List.Find(x => x == y) the operation will be O(n).

List add operations can be costly

When a new List is created; Internally, an array, of a specific size, int[] is created with an initial capacity of N;
After N add operations, the array is not big enough. A new array with more capacity is created, the contents of the current array are copied, the previous array gets discarded, and the new element is added.

An operation to add an element to a List can be costly because it can cause memory relocations, which makes the operation possibly slow. Usually, the List is allocated with enough space, but attention should be given to this for a list where large datasets are being inserted.

Example of an O(n) operation using RemoveAt(0) with a List

It's important to note that we cannot have empty spaces in memory.
When removing the first element in a list, all its elements must be moved (-1 positions) in memory. This means that removing an element at for a list of n elements:

At [0] position of an array is an O(1) operation
At [x] position of an array is an O(n-x) operation
At [n-1] position of an array is an O(n) operation.

Or we can say that the RemoveAt() method is an O(n) operations where n is (Count - index).

Do not perform O(n) operations inside a loop!

Look at the following piece of code:

for(int i = lst.Count-1; i ≥ 0; i- - ){
   if(isPair(anotherList[i])){
      lst.RemoveAt(i);
   }
}

The RemoveAt() is O(n), and the entire loop could be in the worst case also O(n), which creates a complexity of O(n²), which should be avoided whenever possible; this is even a bigger problem for large datasets. In general, we should avoid O(n) operations inside loops. An alternative to this is using LINQ method RemoveAll():

    list.RemoveAll(x => isPair(x));

SortedList

Functionally a dictionary
Internally uses a list
Uses less memory than SortedDictionary

LinkedList

This is a very well known data structure where it's data elements order is not given by their physical placement in memory. Instead, each element points to the next.

Optimized for fast changes (adding and removing is fast). Very scalable.
Contrary to a List, when removing an element in the middle of the LinkedList, there is no need for memory relocations. Only update the references in the previous and next node.
The lookup is slow (because we have to jump from one place to another).
Under the hood, the data is saved to a LinkedListNode.
No direct indexed element access.

Because of its optimization for changes, a LinkedList could be used as a temporary working set for operations that are performing a large number of changes to it; it can then be copied to another collection when done with editing the List.

Dictionary and related types

Features of a Dictionary

Lists are not suitable for lookups in large data sets; the Dictionary fetches an element for the cost of O(1) when trying to get an element from it!
The Dictionary uses keys to index its elements; they can be of any data type, some better than others. The keys are case sensitive, and we must specify a StringComparer when using string keys to avoid problems.
The Dictionary returns a key-value pair and not just the value.
The items in a dictionary are not ordered.
When using custom types for the key, we must implement an IEquatable interface and specify an override to the following methods: "bool Equals(object obj)" method, and the "GetHashCode(…)" method.
- Optionally, you can also specify the "bool operator==" operator.
Make sure to have consistency between the Equality comparator and the HashCode generator. Take advantage of existing MS implementations.

SortedDictionary

Keyed access to items
Sorts items only by key
Guaranteed sort order when enumerating
Modifications scale better

Stack

We pop the last item in the collection and push items to it.
Useful when we have items (or tasks) to be processed. New items are added to the collection; Items are removed as they are processed.

An Undo operation is a good use case of this data structure.
Items are stored in order (like List ).
Retrieving an item removes it.
No direct element lookup.
Provides the most recent item in the collection.

Queue

Behaves like a real queue; the first item in is the first item out (FIFO).
Retrieving an item with "Dequeue()" removes it from the queue, but we can use "Peek()" to see the next item in the queue without removing it.
No direct element lookup but supports enumeration with the foreach loop.
Provides the item waiting the longest time in the queue.

HashSet

Useful to enforce uniqueness out of the box.
Allows for set operations (unions and intersections).
Similar to dictionaries (But lack keys and don't support lookups).

HashSet for dealing with duplicates

There are two ways to deal with unwanted duplicates: the native way and the better away (just kidding, kind of).

The naive way:

var uniqueListOfNumbers = listOfNumbers.Distinct().ToList();

This strategy works fine for small collections but is not ideal for extensive collections.

The better way

Another strategy is to use a HashSet; this way, when we are adding elements to the HashSet, it will ignore duplicate values when adding them to the set! It's very scalable and efficient at enforcing uniqueness.

Comparison between Dictionary and HashSet

They are both unordered bags of objects and use similar data structures internally.
Dictionaries have keys and use them to perform lookups | HashSet does not have keys and does not support lookup (only enumeration).
Dictionaries have unique keys | HashSet has unique values.
Dictionaries throw an exception when adding duplicates | HashSet ignores when adding duplicates.

SortedSet

Used to order a set as you add elements to it.
Requires that an implementation of IComparer is provided so that the sorted set can use it to compare elements when sorting. * We are the ones that decide how the sorting happens.

Read-Only Collections

Read-only collections only allow reading of the collection (pretty self-explanatory). This is useful if you have a collection that you want to be able to modify internally, but you want it to be read-only to external users of your library or application.

Caution ReadOnlyDictionary it's not really read-only

When we update a standard Dictionary , and we then create a new ReadOnlyDictionary based on the standard dictionary Dictionary the changes will also be reflected in the ReadOnlyDictionary, maybe defeating our initial goal. To avoid this, we use ImmutableDictionary, which will guarantee that no changes are made to the collection.

This happens because the ReadOnlyDictionary adds a read-only wrapper around the original collection reference! This is true to all ReadOnly collections.

Immutable Collections

An immutable collection prevents any changes to the collection. It's useful to enforce that a dataset should not be tampered with, possibly avoiding other programmers to introduce bugs in your code.

Although immutable collections cannot be modified by "normal" C# code, they could be manipulated with reflection or unmanaged code.
Immutable collections are guaranteed to be thread-safe because of their immutable nature.

Some notes about time complexity in collections

As you should know, the time complexity of any piece of code is an approximation of the time (it's not an absolute measure) that piece of code takes to execute. With collections, it will tell you how the performance scales as the collection size increases.

O(1)

Represents a constant time to execute the operation, independent of the size of the collection.

It's the lookup time for an indexed lookup in an array or List.

O(n)

Represents a time that scales linearly with the size of the collection

Removing the nth item from a list.
The time to enumerate a collection with n items.

O(n²)

Represents a time that scales in a non-linear way.

Very slow for extensive collections
Rare in .NET, unless we do something like putting an O(n) operation inside a loop.

O(log n) & O(n log n)

Found in some collections that use more complex algorithms than just arrays under the hood.
For huge collections, O(log n) performs as good as O(1).
For huge collections, O(n log n) performs as good as O(n).

References

[1]. Arrays - https://docs.microsoft.com

Things you need to know as a C# developer - Build types

Sam Fields — Sat, 05 Sep 2020 20:37:33 +0000

This post is part of a series of posts that I'm using to compile the most significant bits and tips about several things in C#. The purpose of this post is to be used as a way of review or quickly learn something new about C#.

In the first post of this series, we will summarize the C# build types, where every variable type is either a value type or a reference type.

Value Types

Variables that are value types contain their data, meaning value types are the value themselves. Below are some of the properties of this type:

Types like a struct, int, float are value types.
Each variable holds an independent instance or copy of the type.
Value changes to the variable do not affect other copies.
The value in the variable is the information.
Because it is not a reference, it cannot be null.
You might have to check the variable for null.

Passing Value Types by Value

Passing Value Types by Reference

In some cases, passing value types by value can create a performance bottleneck because the value passed (and copied) can be a complex data structure. Therefore, it can be a good idea to pass those data structures by reference. Bellow, a more straightforward example, shows how this works:

Reference Type

Variables of reference types store references to their data (objects), meaning that reference types reference something.

All C# classes are reference types.
The object instance shares its data, amongst other copies.
Value change affects all the references pointing to it.
The variable can point to nothing => it can be null.
Null checking may be required.

Passing Reference Types by Value

This example displays all the ways a reference can behave:

Passing Reference Types by Reference (using the ref keyword)

Reference types behave slightly differently when you use the ref keyword. The example below displays how the ref keyword can affect a variable when passed to a method:

Important Notes

The CLR can store objects in three locations: registers, stack, or the managed heap.
A value type does not exist exclusively in the stack! It can exist in any of those three locations.
A reference type can exist either on the managed heap or the stack. The location of the variable in memory depends on many factors. It's scope, the lifetime of the variable, and the implementation of the CLR.
Use the ref keyword to avoid copies of complex value type data structures.

Quiz

1 What's the main difference between a value type and a reference type?

A value type holds the value itself, and a reference type holds a reference "memory address" to the value.

2 How do you pass a value type variable by reference to a method?

To pass a value type parameter by reference, we can use the "ref" keyword available since C# 7.0.

3 Value type variables are stored wherein the memory landscape?

Contrary to popular belief, value types can either be stored in the stack or the managed heap. In some cases, depending on the variable lifetime, it might even be stored in a register. It's difficult to pinpoint the precise location at any given point since the CLR implementation must also be taken into consideration.

References

[1]. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/passing-reference-type-parameters

[2]. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/passing-value-type-parameters

DEV Community: Sam Fields

Things you need to know as a developer - Clean Coding

Introduction

Table Of Contents

Clean Code

Why?

1. Reading code is harder than writing code!

2. "I will make this better later..."

3. Technical Debt

4. I'm a lazy programmer

5. Clean code vs Development Speed

Choosing the right tools

The email validation nightmare

Example of a possible email regex in C\

Example of an email regex in other languages

An alternative for .NET developers

Keep things separated

Code metrics

Things to avoid when writing code

High Cyclomatic complexity

Zombie Code

Excessive indentation and no whitespaces

Long classes and methods

Unnecessary comments

Poorly named data structures and variables

Overly verbose names

DRY principle´

Self-documenting code

Conclusion

LINQ: Caveats and pitfalls

Table Of Contents

LINQ

Extension method syntax

Query method syntax

Execution types

Imediate execution

Deferred execution

Deferred Streaming Execution

Deferred Non-Streaming Execution

What is query evaluation?

Things that force query evaluation

Enumerating with a foreach;

Chaining to deferred extension methods a method that does not implement deferred execution

Comparing how deferred and imediate execution works

Custom filter method using immediate execution

Custom filter method using deferred execution

Dangers with deferred execution

Deferred exception execution

Multiple enumerations

The performance problem

Pipeline A

Pipeline B

The consistency problem

🧠🤔 Things to remember:

Algorithms Every Developer Should Know - Binary Search

Table Of Contents

Binary Search Algorithm

Definition

Time Complexity

Auxiliary Space

A step by step look at the algorithm

Edge Cases

1. The element might not exist in the array

2. The target value could be in the rightmost or left most side of the array

3. The target value could be the initial, middle element

4. Duplicate entries could exist in the array

Implementation of the Binary Search algorithm using an iterative approach

Implementation of the Binary Search algorithm using a recursive approach

Generic implementation of the binary search algorithm in C#

Explore the code

Things you need to know as a C# developer - Collections

Table Of Contents

Arrays

Features of an Array

Collections

Common features of almost all collections

Selecting the best collection for the job

Taking a look at the .NET collections

Lists

List add operations can be costly