Big Scare

I learned an important lesson. Actually, I learned a few lessons. The first lesson - always back up. Have copies of files if backing up isn't easy. Next, it's a good idea to not proceed too far without checking to make sure everything still work, while you can still undo something. Third, and more specifically, apparently, renaming certain items in Visual Studio can completely erase a design. Let me explain...

To recap, Visual Studio is the IDE I use to write my programs. I'm learning the VB.Net programming language because that's the language the software my company maintains was written in. It makes sense to get more familiar with that. I'm still extremely new to Visual Studio, and I'm very new to coding and general coding principles. I'm reading tons of books (often at the same time) to get general coding practices, as well as very specific programming details for VB.Net. All this combined to say, I'm still learning, and I'm really new.

Now, I'm creating windows forms and writing the code to go along with them. I love creating the form itself, and that's the screenshot I showed in my previous blog post. I needed to do something I've never done before on this new pet project of mine. I needed to create a new Form within this solution. Luckily, I had watched demos during my meeting with all of developers a week ago how to add objects, and I managed to create one. Through creating subs before, I learned that case of letters was important. You'll see this error often.

Pretty much, Subroutines have to begin with a capital letter. This makes sense, but it's still somewhat conflicting. I've learned through the research I've done that when you name buttons, labels, and boxes in the designer, you name them with a lowercase prefix convention. For instance, my title "Detailing Calculator" is called lblTitle. This is fine for a label. For a button, however, you do the same thing (btnAngle1). So, to get to the code for that button, you can simply double-click and you're taken to it. The "rub" is that Visual Studio automatically renames the Subroutine the button you chose (which means my Subroutine was btnAngle1 - not BTNAngle1). So, I get the error. I got used to that and got rid of the errors. I simply renamed all of my Subroutines as they're created.

Now to the good stuff. When I created the form, the prefix for the form is frm. Again, the Subroutine I renamed to FRMxxxx. Then, in this tree, I literally renamed the Subroutine FRMAngle. I noticed that my DetailingCalculator.vb wasn't following the same prefix, so I decided to fix that.

I decided to rename the Public Class to FRMDetailingCalculator. Apparently in doing this, it completely erased and trashed my design. I panicked for a while that night, and eventually gave up. I didn't even realized it happened. But it did. 

I got with one of the developers here at work the next day over a Skype call. He had me look in the recycling bin and restore the .resx file and other DetailingCalculator file from there to the folder all of the other project data was stored in. I restarted Visual Studio, and all is well again.

So, to sum up. Have a backup copy. I was very fortunate to have the files still in the recycling bin, and even more fortunate to have someone walk me through how to restore it. Another big thing I need to make sure I study up on is some basic practices when it comes to naming conventions, classes, etc. 

Updated Resources

I've been reading a great book called Learning Visual Basic .Net by Jesse Liberty. You can get the Kindle download from Amazon here for just over $15. It's very specific and detailed from what I've seen so far, and I'm hoping it's going to take some of the mystery out of the programming and coding practices.

In addition to this, I'm listening to an Audio Book from Audible called Soft Skills: The Software Developer's Life Manual by John Sonmez. Audible is great, but if you want the book, Amazon has it here. I'm also reading The Software Craftsman by Sandro Mancuso. My company bought that book, and we have monthly meetings to discuss what's been read so far. Link to it is here. Finally, I've been reading a book on the side by Robert C. Martin (a very well-known coder) who has a blog titled "Clean Coder" you can get to here. The book I'm reading by him is called The Clean Coder: A Code of Conduct for Professional Programmers. The link to that book is here. 

At first, when I stepped back, this seemed like an overwhelming amount of material to read. Mind you, the only books I listed are the ones related to programming; I'm also reading the Benjamin Franklin biography on the side, but at a very slow pace. The more I thought about it, the more I realized that this is very similar to the way school is done. There are a multitude of subjects learned at one time, and usually, it opened new ways of thinking about those subjects when all of the learning happened at once. Besides that, each book teaches a different area. The book Learning Visual Basic .Net book is very detailed and gets into extreme specifics, which is important. Soft Skills is a much, much broader book. Rather than focus on programming specifically, this teaches how to handle a career and be successful at programming. The book Clean Coder is a little broader, but has some real technical skills involved; it complements Software Craftsman very well. Many of the ideas overlap, but at the same time, a very broad area is covered.