DEV Community: TSOTSI1

Untangling `.npmrc` Configuration and Authentication: A Journey Down the Rabbit Hole

TSOTSI1 — Tue, 12 Mar 2024 13:52:00 +0000

When working with Node.js and npm, the .npmrc file becomes an integral part of your development environment. It contains crucial configurations that dictate how your npm installations behave. Yet, the details of the .npmrc file and the authentication principles behind it often remain shrouded in mystery. Today, let's uncover these less-travelled paths and make sense of the wonderland that is .npmrc.

Understanding `.npmrc`

The .npmrc file is a configuration file for npm. It can be located in four places, each corresponding to a different level of configuration:

Per-project configuration (in your project root): /path/to/my/project/.npmrc
Per-user configuration (in your home directory): ~/.npmrc
Global configuration (in the npm install directory): $PREFIX/etc/npmrc
Built-in npm configuration: /path/to/npm/npmrc

Each level has its use cases, but the real magic lies in understanding and manipulating these files for a smoother and more customized development experience.

Diving into Authentication

When it comes to private npm registries, authentication becomes vital. Typically, npm uses authentication tokens, which can be set in the .npmrc file using the npm login command. This token is sent with every request to the registry to confirm your identity.

The creation of these tokens involves a process called token-based authentication, where the client exchanges valid user credentials for a token. This token then serves as a key to access the specified resources, thereby preserving the security of user credentials.

The Uncommon Corners of `.npmrc`

While the fundamentals of .npmrc and npm authentication are widely discussed, some subtleties often go unnoticed.

Scoped Registries

One lesser-known feature of .npmrc is the ability to set up scoped registries. With scoped registries, you can specify different registries for packages based on their scope, allowing for a high degree of customization. It is particularly useful when working with a mix of public and private packages.

Environment Variables in `.npmrc`

Did you know that you can use environment variables in your .npmrc file? This is a nifty feature when dealing with sensitive data like authentication tokens, which you might not want to commit to your source control. You can set these variables in your environment and refer to them in your .npmrc file as ${VARIABLE_NAME}.

Two-Factor Authentication (2FA)

In the context of npm and .npmrc, Two-Factor Authentication (2FA) provides an extra layer of security when publishing packages or when an authentication token is created. The additional step of confirming the user’s identity using something they have (like a mobile device) prevents attackers from taking over a user's account, even if they have the token.

Wrapping Up

The .npmrc file and the authentication process behind npm provide a complex yet fascinating landscape to navigate. By understanding the nuances, you can not only streamline your npm experience but also enhance the security of your packages.

In the rapidly evolving world of web development, remember to go beyond the beaten path and delve into the uncommon corners. After all, sometimes the road less traveled leads to the greatest treasures. Happy coding!

The Basic Principles of Clean Code

TSOTSI1 — Tue, 12 Mar 2024 13:51:09 +0000

Writing code is an art, and like all art, it must be done with care and a sense of craftsmanship. In this article, we'll explore the basic principles of clean code, which can help you write code that is easier to read, maintain, and debug.

1. Use Descriptive Names

When naming variables, functions, classes, and other entities, use names that clearly express what they represent. Avoid using abbreviations or single-letter names that don't provide any context.

2. Write Functions that Do One Thing

Each function you write should only do one thing. If a function is doing multiple things, it's a sign that it should be broken down into smaller functions. Each function should be small, ideally less than 20 lines of code.

3. Keep Function Arguments to a Minimum

The more arguments a function has, the harder it is to understand and use. Aim for no more than two or three arguments per function. If you find that a function requires more arguments, consider if it might be better to group related arguments into an object.

4. Avoid Side Effects

Functions should avoid altering any states or producing any effects that aren't related to their main purpose. These "side effects" can lead to bugs that are hard to track down and understand.

5. Write Code Once

Don't repeat yourself (DRY). If you find yourself writing the same code in multiple places, consider how you can refactor to avoid repetition. Code duplication makes your codebase larger than necessary and can lead to bugs if the duplicate code gets out of sync.

6. Comment Wisely

Use comments to explain the 'why' rather than the 'what'. Comments should be used to explain the purpose of the code, any limitations, and how it's used. Avoid unnecessary comments that don't add any value.

7. Code Formatting

Consistent code formatting is important for readability. This includes indentation, spacing, and the use of braces. Many teams use a linter or a code formatter like Prettier to enforce a consistent coding style.

8. Error Handling

Error handling is not an afterthought; it should be planned from the start. Functions that might fail should throw exceptions, and these exceptions should be caught and handled appropriately.

9. Keep Your Code Simple

Avoid over-engineering. Write the simplest code that can solve the problem at hand. Resist the temptation to use complex patterns or fancy language features when they're not necessary.

10. Test Your Code

Testing is not optional. Every piece of code you write should be tested, ideally with automated tests. Tests give you confidence that your code works as expected and allows you to make changes without fear of breaking things.

Conclusion

Clean code is all about readability and maintainability. It's about writing code that is easy to read, easy to understand, and easy to change. These principles provide a solid foundation for writing clean code, but remember that every principle has exceptions. The key is to use your judgement and aim for code that is clean and efficient, without becoming a victim of dogmatism.

7 Unique Insights into the Principles of Clean Code

TSOTSI1 — Fri, 16 Jun 2023 01:12:00 +0000

When discussing clean code, many commonly talk about using descriptive names, keeping functions small, or avoiding code duplication.

While these principles are essential, they don't paint the entire picture. In this article, we'll dive into some less discussed but equally critical aspects of writing clean, maintainable code.

1. Embracing YAGNI (You Ain't Gonna Need It)

YAGNI is a principle of extreme programming that suggests developers should not add functionality until deemed necessary.

While it might be tempting to add 'flexibility' to your code because you 'might need it in the future', it often leads to unnecessary complexity. Stick to the requirements, and don't write code that you ain't gonna need.

2. Considering Code as Liability, Not an Asset

An unusual but pragmatic perspective on code is to view it as a liability rather than an asset. Every line of code written has an inherent cost.

It needs to be understood, maintained, and tested. Before writing more code, ask if the feature is essential or if there's a simpler way to implement it.

3. Proactive Refactoring

Refactoring is often seen as a chore – something to be done 'later'. But proactive refactoring, or continuously improving the codebase as part of the development process, leads to cleaner code.

If you see an opportunity to improve the code, take it. As the saying goes, "leave the code better than you found it".

4. Valuing Readability Over Cleverness

Writing clever code might feel satisfying, but if it comes at the expense of readability, it's not clean code.

Prioritize writing code that is easy to understand over code that's 'smart'. Remember, code is read more often than it is written, so optimize for the reader, not the writer.

5. Treating Performance Optimization with Caution

While high performance is important, premature optimization can lead to overly complex code that is difficult to read and maintain.

The first priority should be writing clear, correct code. Once that's in place, use profiling tools to identify performance bottlenecks and optimize as necessary.

6. Embracing Simplicity Over Completeness

It might be tempting to build a complete system with all possible features.

However, keeping the codebase small and simple is crucial for maintainability. A minimal but well-implemented feature set often serves better than an exhaustive list of poorly maintained features.

7. Using Code Reviews as a Learning Opportunity

Code reviews are not just about finding bugs or enforcing coding standards.

They're also an excellent opportunity to learn and share knowledge. Encourage open discussions, ask questions, share insights, and you'll find that your team's ability to write clean code improves over time.

To boost your Code Reviews, kindly refer to this article. Enhancing Code Reviews with Conventional Comments

Conclusion

Writing clean code is not just about following a set of rules. It's about a mindset that prioritizes readability, simplicity, and maintainability. It requires continual learning and adaptation.

Embrace these principles, and you'll find yourself writing cleaner, more maintainable code in no time. Happy coding🤘!

Harnessing the Power Strictly Typed Forms in Angular: A Simple Tutorial

TSOTSI1 — Mon, 12 Jun 2023 00:53:32 +0000

When working with Angular, handling forms is a common task. However, forms can get complicated very quickly, and ensuring type safety can become a struggle.

That's where Angular Typed Forms come in. Let's dive into how we can leverage typed forms to make our applications more robust.

Understanding Angular Typed Forms

Angular provides two ways to work with forms: template-driven and reactive. While both have their benefits, reactive forms provide more flexibility and are better suited for working with typed forms.

Angular Typed Forms is an innovative approach to reactive forms that brings strong typing into the picture. With typed forms, you define your form controls and groups using interfaces, helping you to maintain type safety.

Setting Up a Book Collection Typed Form

Suppose we're working on a form for a book collection. We'll start by defining an interface for our form data.

interface BookForm {
  title: string;
  author: string;
  genre: string[];
  publicationYear: number;
}

Now, we'll use this interface to create a typed form group.

const bookForm = new FormGroup<BookForm>({
  title: new FormControl(''),
  author: new FormControl(''),
  genre: new FormArray<string>([]),
  publicationYear: new FormControl(''),
});

Manipulating Typed Form Values

One of the most common operations on forms is getting and setting values. With typed forms, this becomes straightforward, and the compiler will warn you if you're accessing or assigning properties that do not exist on the interface.

// Getting values
const bookTitle = bookForm.controls.title.value;

// Setting values
bookForm.controls.publicationYear.setValue(2023);

Working with Form Arrays

Form arrays are used when you have a variable set of controls. With typed forms, you can handle form arrays with ease.

Here's how you add a new genre to the array in our book form:

bookForm.controls.genre.push(new FormControl('Science Fiction'));

This way, working with forms becomes more intuitive, and you get the benefit of strong typing, which prevents many common mistakes that might be overlooked when dealing with 'any' types.

Conclusion

By using Angular Typed Forms, we ensure that our forms are type safe. It brings in an extra layer of security to our applications by enabling us to leverage TypeScript's powerful typing.

It makes our code cleaner, easier to understand, and less prone to errors. The typed forms provide a simple, yet innovative way to handle the complexities of form management in Angular, making your development process much more efficient and enjoyable.

Thanks for reading, and happy coding🤘!

Enhancing Code Reviews with Conventional Comments

TSOTSI1 — Sun, 11 Jun 2023 01:00:09 +0000

In software development, code reviews are a vital practice that ensures code quality, promotes consistency, and fosters knowledge sharing. Yet, at times, they can drive me absolutely bananas!

However, the effectiveness of code reviews is contingent on clear, concise communication. This is where Conventional Comments play a pivotal role.

Conventional Comments provide a standardized method of delivering and receiving feedback during code reviews, reducing misunderstandings and promoting more efficient discussions.

What are Conventional Comments?

Conventional Comments are a structured commenting system for code reviews and other forms of technical dialogue. They establish a set of predefined labels, such as nitpick, issue, suggestion, praise, question, thought, and notably, non-blocking. Each label corresponds to a specific comment type and expected response.

Labels instances:

Labels	Description
praise	Highlights something positive. Always look for something to sincerely praise.
nitpick	Trivial, preference-based requests. These should be non-blocking by nature.
suggestion	Proposes improvements to the current subject. Be explicit and clear on what is being suggested and why it is an improvement.
issue	Highlights specific problems with the subject under review. These problems can be user-facing or behind the scenes. It is strongly recommended to pair this comment with a suggestion.
todo	Small, trivial, but necessary changes. Distinguishing todo comments from issues or suggestions helps direct the reader's attention to comments requiring more involvement.
question	Appropriate if you have a potential concern but are not quite sure if it's relevant or not. Asking the author for clarification or investigation can lead to a quick resolution.
thought	Represents an idea that popped up from reviewing. These comments are non-blocking by nature, but they are extremely valuable and can lead to more focused initiatives and mentoring opportunities.
chore	Simple tasks that must be done before the subject can be “officially” accepted. Usually, these comments reference some common process.
note	Always non-blocking and simply highlight something the reader should take note of.
typo	Typo comments are like todo:, where the main issue is a misspelling.
polish	Polish comments are like a suggestion, where there is nothing necessarily wrong with the relevant content, there's just some ways to immediately improve the quality.
quibble	Quibbles are very much like nitpick:, except it does not conjure up images of lice and animal hygiene practices.

Decoration instances:

Decoration	Description
non-blocking	A comment with this decoration should not prevent the subject under review from being accepted. This is helpful for organizations that consider comments blocking by default.
blocking	A comment with this decoration should prevent the subject under review from being accepted, until it is resolved. This is helpful for organizations that consider comments non-blocking by default.
if-minor	This decoration gives some freedom to the author that they should resolve the comment only if the changes end up being minor or trivial.

For instance, a suggestion tag signifies a possible improvement proposed by the reviewer, but it isn't obligatory. On the other hand, an issue tag denotes a problem that needs rectification.

The non-blocking tag is used to indicate a comment that should not prevent the code from being merged, but which the author might consider addressing.

How do Conventional Comments Elevate Code Reviews?

1. Improving Clarity in Communication

By standardizing labels and formats, Conventional Comments enhance the clarity of comments, eliminating vague language and misunderstandings, ensuring all participants understand the intent and meaning of the comments.

For instance, if a reviewer writes: "issue: This function might cause a memory leak.", the developer immediately recognizes a problem that requires fixing rather than a simple suggestion or consideration.

2. Providing Structured Feedback

Conventional Comments facilitate a way to organize and structure comments, making code reviews more efficient and aiding developers in understanding and responding to feedback faster.

For instance, a praise comment can directly link positive feedback to a specific piece of code, while a thought comment can propose ideas that might warrant further discussion.

3. Encouraging Open and Constructive Dialogue

Conventional Comments foster open and constructive conversations. By explicitly labeling the type of comment, developers can better understand the nature and intent of the feedback, leading to increased confidence in participating in the review process.

For example, a suggestion comment sparking a deeper discussion could lead to improvements in the code or design and enhance knowledge sharing among the team.

Conclusion

Conventional Comments makes code reviews more effective and productive.

By adopting this structured commenting approach, development teams can improve clarity in communication, provide more structured feedback, and foster open, constructive conversations.

Both reviewers and reviewees stand to benefit from the implementation of Conventional Comments. Happy coding🤘!

Reference: https://conventionalcomments.org/

Exploring HTTP Communication with Refit

TSOTSI1 — Sat, 10 Jun 2023 12:27:23 +0000

Refit is a lightweight, type-safe REST library that empowers .NET developers to create HTTP API clients in a declarative way, reducing redundant code and streamlining your programming process.

While Refit is highly advantageous for simplifying API client development, it's not without its caveats.

Understanding both its powerful features and limitations can help developers optimize their use of this tool.

Installation and Setup

Refit is easily accessible via the NuGet package manager. You can add it to your project by running the following command:

Install-Package Refit

After installation, you're ready to start building your API client.

API Interface Definition

With Refit, API endpoints are declared as interfaces. This approach ensures type safety and aligns with best practices of object-oriented programming. For instance, suppose we have a web service that allows managing artists for a music streaming service. We could define the endpoints like this:

public interface IMusicApi
{
    [Get("/artists")]
    Task<List<Artist>> GetArtists();

    [Get("/artists/{id}")]
    Task<Artist> GetArtist(int id);

    [Post("/artists")]
    Task<Artist> CreateArtist([Body] Artist artist);

    [Put("/artists/{id}")]
    Task UpdateArtist(int id, [Body] Artist artist);

    [Delete("/artists/{id}")]
    Task DeleteArtist(int id);
}

With this interface, we can perform CRUD operations on Artist objects. Each method corresponds to a specific HTTP verb, and parameters translate to parts of the URL or the request body.

Refit Implementation

With our API interface in place, we can now let Refit implement it for us. Using the RestService class, we can construct an instance that provides an implementation of our interface:

var musicApi = RestService.For<IMusicApi>("http://api.example.com");

This instance allows us to make HTTP requests, such as retrieving a list of artists:

var artists = await musicApi.GetArtists();

.NET Core supports registering via HttpClientFactory

services
    .AddRefitClient<IMusicApi>()
    .ConfigureHttpClient(c => c.BaseAddress = new Uri("http://api.example.com"));

Behind the scenes, Refit automatically translates these method calls into corresponding HTTP requests, and automatically deserializes the returned JSON into the defined objects.

Advanced Features: Custom Converters, Authentication and More

Refit offers flexibility in various aspects. You can plug in custom converters if the standard JSON.NET serialization doesn't suit your needs. Similarly, for APIs requiring authentication, Refit allows integrating various authentication methods. You can use HttpClient message handlers to attach auth tokens to your requests or integrate more complex authentication flows.

Handling Errors

Refit throws an ApiException when a response indicates an HTTP error status. This exception provides crucial details like the status code and error content, facilitating error handling and debugging:

try
{
    var artist = await musicApi.GetArtist(123);
}
catch (ApiException ex)
{
    Console.WriteLine($"An error occurred: {ex.StatusCode}");
}

Limitations of Refit

While Refit is a powerful and convenient tool, it has certain limitations and considerations. First, as Refit is built on top of HttpClient, it inherits some of HttpClient's limitations. For instance, control over timeouts, authentication, and cookie handling still needs to be implemented by you.

Moreover, Refit defaults to using JSON.NET as the serialization tool, but this can be configured to use other serialization tools. If you have special serialization requirements, you might need extra configurations.

Additionally, Refit is most suited for standard RESTful APIs. If your API has non-standard features, such as unique URL structures or request formats, you might need to implement these using other means.

Conclusion

Refit is an invaluable tool in the .NET ecosystem, especially for developers working extensively with REST APIs. It encourages cleaner code, enhances productivity, and reduces the likelihood of errors.

With it, you can focus more on your business logic and less on the nitty-gritty details of HTTP communication.

Thanks for reading, and happy coding🤘!

Reference: https://github.com/reactiveui/refit

Entity Framework(EF) Enum issue/bug/feature

TSOTSI1 — Mon, 13 Mar 2023 21:05:20 +0000

There is an issue that I have faced before with the Entity Framework (EF) issue/feature for enums. Even though I used .HasDefaultValue() of EF Core, it still did not work.

The issue at hand is as follows:
https://github.com/dotnet/efcore/issues/15070

When a developer uses an enum as an attribute of a column, the default value will always be the first enum, which is usually 0, and cannot be updated. How can we avoid this issue until the feature is fixed or modified? Here are two possible solutions below.

1. Assign specific number(exclude 0) to Enum

public enum State
{
    Walking = 1,
    Reading = 2,
    Drinking = 3,
}

Pros: The solution is clear and easy to understand.

Cons: It requires maintenance, as every individual needs to assign a specific number to the enum value.

2. Make default value as the first attribute of enum

public enum State
{
    Walking,
    Reading,
    Drinking,
}

Pros: There's no need to assign a number, and the enum remains clean.

Cons: To prevent someone from modifying the enum without understanding, test cases are needed.

Summary

I personally used the approach of making the default value the first attribute of the enum. In my opinion, this is a cleaner approach and it only requires one test case to ensure that the order is not accidentally changed.

On the other hand, assigning a specific number (excluding 0) to each enum attribute can be a big effort, especially if an enum has over 100 attributes. It can become quite messy.

Ultimately, it's important to pick one approach to ensure that the data in the database is what you want. Any discussions on this topic are welcome. Thank you!

Naming Things in Program

TSOTSI1 — Sun, 15 Jan 2023 13:36:36 +0000

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Whether Phil said this quote or not. In my opinion, I totally agree with the naming of things, especially since English ain't my mother language.

Good naming would let your objects proud to ask: "Say my name", and speak loudly like Mr. White in Breaking Bad. So how to name things? There are some concepts that come below.

1. Don't abbreviate names

There is a classic example, you shouldn't name variables with a single letter. That won't tell you anything about the variables, for instance.

❌ int y = 3;
✅ int seconds = 3;

For class or function naming, abbreviating will easily make your team member or other developers who can't realize it at first sight, even yourself(After a few days you are back to check your code). See these instances below.

❌ abbreviate

Public void MoveOnPg()

✅ not abbreviate

Public void MoveOnPage()

2. Don't put types in variable names

Many books before usually recommend putting the type in the prefix of the variable, but now with statically type languages, we don't need to do that.

❌ type variable

bool bIsValid;
int32_t iCount;
uint32_t uNumUsers;

✅ variable

bool IsValid;
int32_t Count;
uint32_t NumUsers;

3. Add units to variables unless the type tells you

The parameters of the function, adding units are clear to whom to use it.

❌ not type variable

void progress(int overdue)

✅ type variable

void progress(int overdueSeconds)

Further, we can add the type instead for this case in C#, and here getting seconds.

void progress(TimeSpan overdue) {
     var seconds = overdue.TotalSeconds;
}

4. Don't put types in your types

There is very common to see people to put types in the types, in particular the pattern in C#, for instance, adding the prefix in interface with "I".

public interface IService
{
    void Configure(IConfiguration configuration);
}

Most of the time people don't care about whether it's an interface, class, or abstract class, they just want to know what they can use, Absolutely, for C# developers it quite makes sense to follow the pattern, since everyone does that, but for other languages, we shall avoid to do it.

Another example is AbstractX, BaseX

class Car: BaseCar
{
    private const double power = 225;
    private const double acceleration= 6.1;

    public Car(): base(power, acceleration)
    {
       ...
    }
}

It's good to rename the "BaseCar" to "Vehicle", and we can also make the child vehicle become a especific vehicle: Sedan.

class Sedan: Vehicle
{
    private const double power = 225;
    private const double acceleration= 6.1;

    public Sedan(): base(power, acceleration) 
    {
       ...
    }
}

5. Refactor if you find yourself naming code "Utils" or "Utilities"

The class "Utils" or "Utilities", isn't a good name to make customers understand what this class can do, until they dig inside, see below.

public class Utils
{
    int number;

    public Utils()
    {
    }

    public int sum(int number1, int number2)
    {
        number = number1 + number2;
    }
    return number;
}

Actually, we don't need this "Utils" class, for the functional we can move this out, and create a sum class instead.

public class Sum
{
    private int result;

    public int Result {
       get {
           return result;
       }
    }

    public Sum(int firstNumber) {
        result = firstNumber;
    }

    public void Add(int number) {
        result += number;
    }
}

When you find there is class naming like this, rename it, or refactor it, hence, don't name code "Utils".

After reference these concepts, I'd like to say 😎

Thanks for reading, and happy coding🤘!

Reference: https://youtu.be/-J3wNP6u5YU

Dotnet, C#, code format on JetBrain IDE Rider

TSOTSI1 — Fri, 13 Jan 2023 04:25:54 +0000

Code review is an unavoidable topic at work for developers. Coding style aside, if the code format is different, that would add difficulty to the code review.

Since then, this article has been about the basic code format for everyone in the same team, which can go through different IDE and platforms. Especially for Jetbrain IDE of C#, Rider. (If anyone is interested in VSCode, we can talk about it later).

Here, I'd like to combine CSharpier and Dotnet format.

Let's get started!

CSharpier

What is CSharpier?

CSharpier is an opinionated code formatter for c#. It uses Roslyn to parse your code and re-prints it using its own rules. The printing process was ported from prettier but has evolved over time.

Quick Start

Install CSharpier globally using the following command.

dotnet tool install csharpier -g

Then format the contents of a directory and its children with the following command.

dotnet csharpier .

CSharpier on Rider Plugin

Steps:
Open Settings -> Plugins -> Search "CSharpier"

After installation, please "On Save" is turned on.

Dotnet Format

What is Dotnet Format?

dotnet-format is a code formatter for dotnet that applies style preferences to a project or solution. Preferences will be read from an .editorconfig file, if present, otherwise a default set of preferences will be used. At this time dotnet-format is able to format C# and Visual Basic projects with a subset of supported .editorconfig options.

Quick Start

Install dotnet format

dotnet tool install -g dotnet-format

Steps:

1.Open Settings -> Tools -> File Watchers

2.Press The “Plus Sign” to Add a Custom watcher
Set the name to “dotnet format on save”

FileType: C#
Scope: Open Files
Program: Write dotnet-format
Arguments: $SolutionPath$ -verbosity diagnostic--include $FileRelativePath$
- Append --fix-style warning to fix any style issues automatically on save.
- Append --fix-analyzers warning to fix any analyzer warnings on save.
  - Advanced (Options)
- Disabled all advanced option checkboxes.
  - All other values were left default

3.Press Ok, and Save Settings.

That's it!
Any feedback is welcome. Happy Coding 🤘!

Dotnet Format setup reference:

https://strepto.github.io/Pause/blog/dotnet-format-rider

DEV Community: TSOTSI1

Untangling `.npmrc` Configuration and Authentication: A Journey Down the Rabbit Hole

Understanding .npmrc

Diving into Authentication

The Uncommon Corners of .npmrc

Scoped Registries

Environment Variables in .npmrc

Two-Factor Authentication (2FA)

Wrapping Up

The Basic Principles of Clean Code

1. Use Descriptive Names

2. Write Functions that Do One Thing

3. Keep Function Arguments to a Minimum

4. Avoid Side Effects

5. Write Code Once

6. Comment Wisely

7. Code Formatting

8. Error Handling

9. Keep Your Code Simple

10. Test Your Code

Conclusion

7 Unique Insights into the Principles of Clean Code

1. Embracing YAGNI (You Ain't Gonna Need It)

2. Considering Code as Liability, Not an Asset

3. Proactive Refactoring

4. Valuing Readability Over Cleverness

5. Treating Performance Optimization with Caution

6. Embracing Simplicity Over Completeness

7. Using Code Reviews as a Learning Opportunity

Conclusion

Harnessing the Power Strictly Typed Forms in Angular: A Simple Tutorial

Understanding Angular Typed Forms

Setting Up a Book Collection Typed Form

Manipulating Typed Form Values

Working with Form Arrays

Conclusion

Enhancing Code Reviews with Conventional Comments

What are Conventional Comments?

How do Conventional Comments Elevate Code Reviews?

1. Improving Clarity in Communication

2. Providing Structured Feedback

3. Encouraging Open and Constructive Dialogue

Conclusion

Reference: https://conventionalcomments.org/

Exploring HTTP Communication with Refit

Installation and Setup

API Interface Definition

Refit Implementation

Advanced Features: Custom Converters, Authentication and More

Handling Errors

Limitations of Refit

Conclusion

Reference: https://github.com/reactiveui/refit

Entity Framework(EF) Enum issue/bug/feature

1. Assign specific number(exclude 0) to Enum

2. Make default value as the first attribute of enum

Summary

Naming Things in Program

There are only two hard things in Computer Science: cache invalidation and naming things.

1. Don't abbreviate names

2. Don't put types in variable names

3. Add units to variables unless the type tells you

4. Don't put types in your types

5. Refactor if you find yourself naming code "Utils" or "Utilities"

Reference: https://youtu.be/-J3wNP6u5YU

Dotnet, C#, code format on JetBrain IDE Rider

CSharpier

What is CSharpier?

Quick Start

Dotnet Format

What is Dotnet Format?

Quick Start

Dotnet Format setup reference:

Understanding `.npmrc`

The Uncommon Corners of `.npmrc`

Environment Variables in `.npmrc`