Improve your odds with the lingua franca of computing.
A boring old C-style language just like millions of developers learned before you, going back to the 1980s and earlier. It’s not flashy, it’s usually not cutting edge, but it is smart. Even if you don’t stick with it, or program in it on a daily basis, having a C-style language in your repertoire is a no-brainer if you want to be taken seriously as a developer.
Microsoft .Net Team Program Manager, Beth Massi, on the open source .NET Core.
You might have heard the news that .NET is open source. In this post I’m going to explain what exactly we open sourced, why we did it, and how you can get involved.
If you’re not familiar with .NET, it’s a managed execution environment that provides a variety of services to its running applications including things like automatic memory management, type safety, native interop, and multiple modern programming languages that make it easier to build all kinds of apps, for nearly any device, quickly. The first version of .NET was initially released in 2002 and quickly picked up steam in many businesses. Today there are over 1.8 billion active installs of the .NET Framework and 6 million .NET developers in the world.
The .NET Framework consists of these major components: the common language runtime (CLR), which is the execution engine that handles running applications; the .NET Framework Base Class Libraries (BCL), which provides a library of tested, reusable code that developers can call from their own applications; and the managed languages and compilers for C#, F#, and Visual Basic. Application models extend the common libraries of the .NET Framework to provide additional libraries that developers can use to build specific types of applications, like web, desktop, mobile device apps, etc. For more information on all the components in .NET 2015 see: Understanding .NET 2015.
There are multiple implementations of .NET, some from Microsoft and others from other companies or open source projects. In this post, I’ll focus on .NET Core from Microsoft.
Complement a good testing program and identify hard-to-find bugs with static analysis.
Let’s consider compiler warnings. They are produced without executing the code, so the compiler is doing static analysis. Their aim is to inform the developer that the code, though legal, is probably wrong. Suppose you were a compiler developer and you wanted to add a new warning; what characteristics must that warning have?
- There must be some statically identifiable pattern to the suspicious code.
- The pattern must be common and plausibly written by a developer; developing a warning for a too-rare pattern or completely unrealistic code is effort that could be better spent on other features.
- The warning must have a low “false positive” rate; a warning must actually identify defective code more than, say, 99% of the time. False positives encourage developers to eliminate the warning by turning the warning off, or worse, by incorrectly changing the code. There must be a way to eliminate the warning without introducing a bug into the code.
- The pattern must be identified extremely Slowing the build process by anything more than a few percent is unacceptable.
I always recommend that everyone use the strictest warning settings on their compiler, to pay attention to warnings, and to (carefully) fix them all. Even fix the false positives; if the code was weird enough to fool the compiler then it’s weird enough to fool a human, and you don’t want to have “expected” warnings distracting you from actual warnings.