Annoying Coding Practices

I am right now in the middle of transferring a piece of functionality from one project (ASP.net 1.1 web application) to a second project (Windows Forms desktop application). Although it is a significant feature, most of the work should be straight copy-paste. It is a large chunk of code written in C#, referencing a business object library shared between the two projects, a bunch of external dlls, etc.

Really, all that I should have to do is to customize the function for my projects codebase, migrate some of the ASP.net aspect to a WinForms environment, and hook it up to my UI. Yet, as I am going through this code, trying to make sense of what is going on, I find myself having to delete/modify/rewrite much more of the code than I should be doing. Although some of this is to be expected, much of it has to do with poor programming practices that if maintained lead to future difficulties with maintenance, poor readability, logic errors and bugs and are detrimental to debugging and testing. True, I have not found so many examples that are worthy of public exhibition, but I have received an education in how poor coding practices can effect a section of code long after the original programmer has completed his (or her) work.

A sampling of some of the things that are currently causing me grief:
Continue reading

.Net Encryption Simplified

Most of the projects that I work on require encryption of some form. Usually Symmetric (the kind where you can use the same password to both encrypt and decrypt), but sometimes asymmetric as well (where you encrypt with one password and decrypt with another). the .Net Framework has rich support for many different types of encryption algorithms, of varying methods and strengths, giving tons of options over how to run an exact implementation. However, one look at the System.Security.Cryptography namespace in the framework can end up leaving the novice user scratching his or her head over how exactly to proceed. Even individual implementation examples found on MSDN regarding individual algorithms are complicated pieces of code. Despite the wealth of code relating to this topic in the Framework, there is no one method (as far as I know) where you can simply put in data and a key, and receive encrypted text in response.
Continue reading

Visual Studio 2005 Add-Ins and Tools That I Use

I am right now in the middle (about 20% and 18K lines of code through) a pretty substantial Windows Forms project using Visual Studio 2005 (C#). Here are some of the add-ins that I have been using (ranked in order of essential to useful):
Continue reading

How-To-Select Guides

New from Mike Gunderloy (of Daily Grind fame), this site will be hosting guides relating to different types of .Net components. From the site:

Our goal is simple: we want to bring you the comprehensive, unbiased information that you need to make an informed choice when picking the components that you need to make your .NET project a success. Each How-To-Select Guide will look at a particular category of components in depth. We’ll offer guidance on what components in that category can do, and show you how to choose between the various components on the market. We’ll also list and evaluate every component that we can in the category (limited only by the vendor’s willingness to provide us with their software to evaluate).

The first guide (How to Select a PDF component for .Netpdf) looks to be very informative – I look forward to more in the future.

Schedule Games

Check out this the Schedule Games series from Johanna Rothman at Managing Product Development (found this via Daily Grind 617):

  1. Schedule Chicken
  2. 90% Done
  3. Bring Me a Rock
  4. Hope is Our Most Important Strategy
  5. Queen of Denial
  6. Sweep Under the Rug
  7. Schedule Dream Time or Happy Date
  8. Pants on Fire
  9. Schedule == Commitment
  10. We’ll Know where we are when we get There
  11. The Schedule Tool is always Right
  12. Acknowledgements

Lots of great advice here. Luckily I have not yet had the misfortune to fall into any of the described situations too seriously…but it’s good to know what to look out for.