The Boy Scouts have a rule: “Always leave the campground cleaner than you found it.” -Robert Baden-Powell-
For us software developers, campground = existing code.
So when fixing a bug or adding a new feature, we clean up all related code right?
If we do so, we end up “polluting” our pull requests.
As a really trivial example, let’s imagine we’re fixing the bug below, followed by a Pull Request.
Bug 🐛: Notice that person.LastName is not set, therefore we get a NullReferenceException in line 12.
Also notice how the IDE warns us of potential code cleanups. E.g…
Last time, we started off by explaining the core concepts of WebAssembly and how you can try it for yourself with little to no setup. If you need a refresher, please refer to this link.
This article is more of a how-to on getting up and running with a production-grade web project which incorporates Rust (or any other language for that matter) and WebAssembly into your web pages.
Nowadays, as front and back end developers we’re used to having tools save us time and avoid human errors by performing mundane tasks such as code compilation, style checking, code organization, optimization…
In most medium to large web API’s, most controller classes tend to use common services such as ILoggers.
Even though ASP.NET Core makes most services easy to access via dependency injection, sometimes initializing controller classes can get repetitive, and thus making it difficult to stick to the DRY principle.
Take the below snippet of code for instance. Out of the five services being injected, probably four of them will be re-used in other controllers. This means each of these controllers will have to be initialized in the same way.
Arguably most speedy developers would agree that it’s best to keep your fingers on the keyboard and away from the mouse.
That said, let’s go over the traditional way of adding files or folders on Visual Studio: