“Everything automatable will eventually be automated.” Have you heard that saying? I’d prefer to tweak it a little bit and say that everything automatable should be automated. If you’re a regular reader of the SubMain blog, you’ll know that we enthusiastically advocate for automation. In today’s post, we continue that trend, focusing on documentation generation. More specifically, we’ll walk you through some essential features you should consider when trying to pick a C# documentation generator. (more…)
We’ve already covered so many C# concepts, and most of them relate to objects. This is hardly surprising, C# being an object-oriented language. What is surprising is that, up until this point, we haven’t covered the “thing” responsible for creating objects!
Today’s post will remedy this problem by covering the C# constructor. The post will roughly follow the same pattern we’ve followed through much of the series. We start by defining the concept, then proceed to show several usage examples. We part ways with general tips on best practices to follow and pitfalls to be aware of. Let’s begin!
C# is about objects, classes, and class methods. The runtime handles memory management so you don’t have to. Your C# code is compiled into an intermediate language and runs on the .NET platform. It’s a language built around productivity; therefore, the compiler does many optimizations so you can write clean, readable code.
There are some general standards that fluent C# writers follow. So, if you’re a developer who’s coming to C# from another programming language, you’ll want to know this stuff too! This post is an introduction to the most important standards and sets you on the course to other resources that can help build your C# prowess.
If you’re a software developer, then I’d bet you use some kind of automated testing. And if you don’t, you certainly should. But what about “automated documentation?” Do you know what this means? Are you putting this technique to work for you? Most likely you’re not. And if that’s the case, you’ve come to the right place.
We’ll start out by exploring the role documentation plays in the modern software development world, which has, by and large, embraced agile methodologies. The post will show that yes, documentation is important and valuable even today.
Then we’ll proceed to cover automated documentation. We’ll start by examining the growing trend of using automation to improve the software development process itself, showing how automation has become a must for companies struggling to remain competitive. After that, we’ll define automated documentation and talk about the benefits it provides.
Finally, we’ll get to the tools, where we’ll briefly cover three tools that can help you and your team with your automated documentation strategy, sharing some final tips after that.
Let’s get started.
If you’re a regular reader of the SubMain blog, you’ll know that we often publish posts about fundamental concepts of the C# language. Today’s post adds yet another chapter to this ongoing series. The topic we’ll cover is, in fact, as fundamental as it can get: C# data types.
As the title suggests, this post will cover the three most common C# data types. For each one of the types, we’ll start out by offering some justification on why the type deserves to be on the list. Then, we’ll proceed to show you some interesting facts you need to know about the type. When relevant, you’ll also see some code examples.
But before we start, there are two questions that need answering. First, what is our definition of a C# data type? And what does it actually mean for a type to be “common”?
When you’re coding by yourself, for yourself, your code style doesn’t matter that much. Developers the world over have GitHub profiles full of horrible, ugly code they wrote to tinker with some new library or language. Their goal wasn’t to write pretty code, it was to learn something new. That changes when you’re working in a software team, though. Now you need to make sure not only that your code is functional, but that it adheres to team standards.
There are many ways to make sure that code written for a professional team meets requirements around styling and complexity. Every team should be doing peer code review before code is promoted to production. This review ensures not only that your code does what it’s supposed to, but also that other people can understand it, and that it meets the team’s style requirements.
Like manual code review, automated code review is a critical part of writing high-quality code.
You’re a little ways into your first programming job, and things are getting easier. At first, all the code you had to deal with might have overwhelmed and confused you, but you’re starting to get the hang of it. That’s great! Now you’re wondering how to take the code you write to the next level. While there are lots of things to learn about your programming stack, many of which will make you a better programmer, there are a few that will serve you no matter what stack you work in. One of those is code documentation.
Many developers don’t write enough documentation, either because they don’t see the value or because they feel like they don’t have time. You don’t need to be one of those developers. With a little time and a lot of practice, you can add documentation for your code that makes reading it a joy to use for both you and anyone else who comes along.
When you first start out with C#, you’ll surely begin by creating a class. This is true whether you’re creating the code by hand or having a tool do it for you. The class is one of the most basic elements of the C# language. It serves many purposes, but the main purpose is for grouping related functions.
There’s more to a class than meets the eye. You can use a class in several ways depending on what style or paradigm of coding you’re using. Also, teams and even codebases often have different naming and casing conventions. In this post, you’ll learn more about the C# class. You’ll also learn about the importance of some best practices, such as following code conventions and using certain patterns.
With that said, let’s get started by outlining a basic class.
Code review is one of the most common topics here on the SubMain blog. Today’s post covers this subject again, this time attacking a very specific angle: code review tools. If you’ve been a software developer for a while, you’re probably familiar with at least a few of them.
But do you know the different types of tools out there? Would you know how to categorize them? Knowing how to do so might be the difference between adopting the right tool for the right situation or being paralyzed by doubt. Which situation would you prefer?
Does the term “XML comments” confuse you? Well, rest assured. You’re not alone. “Does that refer to comments inside an XML file?” you might wonder. Or maybe you have this vague notion that it has something to do with some kind of documentation for programming source code. Both assumptions are kind of right. But you’re still reading this post, which means that “kind of” isn’t going cut for you, right?
So this post is all about XML comments. You’re going to learn what this term actually means, what XML comments are (and aren’t) good for, and learn a thing or two about software documentation. If you’re ready, then let’s get started!