In this chapter, we will have a look at some examples of being more efficient as a developer when it comes to debugging your code. We will also be looking at how to write secure code. Writing secure code can be a challenge, but consider the following: if part of your code security involves making sure that passwords are securely stored, why write that code over and over between projects? Write the code once and implement it in every new project you create. The concepts we will be looking at are as follows:
- Encrypting and storing passwords correctly
- Using
SecureStringin code - Securing sensitive parts of
App.config/web.config - Preventing SQL injection attacks
- Using Diagnostic Tools and Historical Debugging
- Setting conditional breakpoints
- Using PerfTips to identify bottlenecks in code
Something that many developers tend to miss is the need to write secure code. Development deadlines and other project-related pressures cause developers to put delivering code above doing it the right way. Many of you might not agree with me, but believe me when I say that I have heard the excuse of "We do not have budget for this" once too many times. This is usually when the development budget has been determined by other stakeholders and the developer not consulted.
Consider a situation where a consultant tells the developer that they have sold a system to a customer. That system now needs to be developed. Furthermore, the developer is told that they have x amount of hours to complete the development. A document outlining the requirements is given to the developer and the developer is given the go-ahead to begin, and to complete development in the required time.
This scenario is the reality many developers face. You might think that this scenario can't possibly exist, or perhaps you are reading this and relate to the scenario as being how the process currently works in your company. Whatever the case may be, this is something that happens today in software development.
So how do developers combat project suicide? (I call these projects this because projects approached like this rarely succeed.) Start by creating reusable code. Think of processes you repeat often enough to warrant writing a reusable DLL for. Did you know that you can create Visual Studio templates? If you have a standard project structure you use, create a template from it and re-use it for each new project, thereby speeding up delivery and cutting down on bugs.
A few considerations for project templates are database layers, security layers, common validation code (does this data table contain any data), common extension methods, and so on.