Roslyn is a platform which provides the developer with powerful tools to parse and analyze code. It's not enough just to have these tools, you should also understand what they are needed for.
The article can be divided into 2 logical parts:
General information about Roslyn. An overview of tools provided by Roslyn for parsing and analyzing the code. We provide a description of entities and interfaces, as well as the point of view of a static analyzer developer.
Peculiarities that should be taken into account during the development of static analyzers. Description of how to use Roslyn to develop products of this class; what should be considered when developing diagnostic rules; how to write them; an example of a diagnostic.
This article is intended to answer these questions. Besides this, you will find details about the static analyzer development which uses Roslyn API.
More: Introduction to Roslyn and its use in program development
Here is a small e-Book for your attention: The Ultimate Question of Programming, Refactoring, and Everything. This book is intended for C/C++ programmers, but it could be of interest for developers using other languages as well.
What makes the book peculiar is the descriptions of real, not theoretical cases at the base of it. Each chapter starts with a code fragment taken from a real application, and then the author gives various tips of how this bug could be avoided. The questions touched upon in this book can help the readers improve the personal coding style and the coding standards used in the team.
CppCat is a static code analyzer integrating into the Visual Studio 2010-2013 environment. The analyzer is designed for regular use and allows detecting a large number of various errors and typos in programs written in C and C++. For the purpose of popularizing it, we've decided to launch a student-support program granting free licenses to every higher school student who will contact and ask us about that. You just need to send us a photo of your student card or transcript.
I have studied numbers of errors caused by using the Copy-Pate method and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have never seen this phenomenon described in books on programming, so I decided to write about it myself. I called it the "last line effect".
You are so lucky to be a programmer. I would like to be the programmer.
- Why do not you learn?
- I already tried. I checked out codeacademy and other websites, but it is not mine.
- Yep, the programming is not really for everyone.
- You are well paid, and you can create different things. Almost every day you get some crazy offers at least for 100 thousand dollars.
- Yep, honestly it's very flattering and a little mind-blowing.
- You get your share in the company and you know that the software engineers are always respected. You can implement any idea in the app and get rich. Moreover, you do not need to hire anyone for this.
- Actually, the programming makes me miserable.
- Wow. What do you mean by that?
- In order to be a good programmer, I need to develop a special mindset and that makes me sad. I noticed this in other programmers, of course, not all, but in many.
- What is this mindset?
- This is concentration on the strengths, and not on the weaknesses.
- Why do you need this to become a good coder?
- I work like this:
I think that each of you tried to find the own way to solve tasks in the learning process of a relational database management system, and not knowing that out there are various helpful features, which could speed up the queries at times and reduce the code size. In this article I want to share with you my experience, namely how to work with MySQL comfortably, often allowing the programmer to do the things that other databases would not be able to do. This material would be useful rather for those who just decided to delve into the wonderful world of queries, but maybe the experienced programmers will find something interesting for themselves here.
Perhaps, this article may not present any new or fresh ideas, besides, I'm sure you have often read something like this somewhere else. This post even does not claim the fact to be true. Its content is the fruit of my own experience, mistakes, and the knowledge that I have gotten from my colleagues. I'm sure that many people will be able to find themselves in my article. Probably, the first stage is not very typical for the programmers who are not involved in the Olympic programming, but the following stages do not independent from this factor at all.
In this article I'm going to discuss a problem few people think of. Computer simulation of various processes becomes more and more widespread. This technology is wonderful because it allows us to save time and materials which would be otherwise spent on senseless chemical, biological, physical and other kinds of experiments. A computer simulation model of a wing section flow may help significantly reduce the number of prototypes to be tested in a real wind tunnel. Numerical experiments are given more and more trust nowadays. However, dazzled by the triumph of computer simulation, nobody notices the problem of software complexity growth behind it. People treat computer and computer programs just as a means to obtain necessary results. I'm worried that very few know and care about the fact that software size growth leads to a non-linear growth of the number of software bugs. It's dangerous to exploit a computer treating it just as a big calculator. So, that's what I think - I need to share this idea with other people.
A couple years ago, I worked together with Ken Thompson on the interactive graphics language that was developed by Gerard Holzman in Bell Labs. I was typing quicker, therefore, I sat at the keypad, and Ken stood behind me. We worked quickly and when the compiler gave out an error, I started reflexively digging in a problem, studying the call stack, program output and launching a debugger, and so on. But Ken simply was standing nearby and thinking, ignoring me and a code, which we just wrote. Soon I noticed regularity that Ken often understood the problem faster than me and was saying, “I know, what is going on”. Usually, he was right. I understood that Ken built the mental model of a code, and when something was broken, it was the error in this model. He was thinking of how this problem could arise, so he explained what was wrong with model, or where our code could mirror this model incorrectly.
I have little experience (summarily I have been working as a programmer nearly for 16 months), nevertheless, I would like to give some tips to myself in the past, or in other words, to those who are studding now at the university and planning to become a software developer. I do not have a claim on wisdom or experience on no account. While thinking a little, I understand that all these tips are very actual for me more than ever too. I published the first note in my blog last year, and now I am publishing here the list expanded with tips of the readers of this blog.
All tips are independent and their order does not matter.