When a code base is being worked on by many developers, it helps to have tools to find problem areas and keep the code maintainable. Sometimes developers have bad habits that need to be trained out of them. There are many articles out there about advanced code metrics and tools to track when they get better or worse, but like with most other things, it is best to use more basic approaches first. One such simple approach I use with C# is looking for uses of certain problematic keywords in spaghetti code, especially when dealing with developers coming to .Net from a C or C++ background.
From most heinous (and obvious) to least, those keywords are: goto, unsafe, ref, and out.
This one shouldn’t take much explaining. I believe it widely accepted that if you see goto in someone’s code they were drunk and trying to accomplish something that was way over their heads to begin with. Although code that somehow contains goto will probably get cleaned up the first time a sober developer touches it, you should occasionally check for it just because code that problematic will probably produce hard to find and reproduce bugs.
This one is more controversial than goto. After all, it is easy to come up with examples where unsafe code is actually needed. On the other hand, people who have been developing in .Net for a long time may not realize that new converts from C++ may somehow think that 20 lines of complex void pointer manipulation is superior to 60 or so lines of type-safe code. I’ll grant that that 20 lines is probably faster, but if you are doing something that requires that type of performance in C# you probably chose the wrong language. As a general rule of thumb here at FrogSlayer we tend to require significant code documentation as to why unsafe was necessary anywhere it is used.
ref and out
Reference parameters (specified by the ref and out keywords in C#) are lesser evils of both hard to read code and bad object-oriented design. When someone is skimming code to find the source of a bug, or to find the right place to make a change, reference parameters tend to violate the rule that on an assignment, the variables being changed are to the left of the assignment operator. From a design perspective, frequent use of them implies that you are missing a type in your architecture , namely the type those methods should be returning. There are a few cases (like tryParse functions) where a new type for the result doesn’t make sense and where performance gains are significant enough to justify returning multiple values. But those cases are relatively rare and almost never justify the use of a ref parameter.
In short searching you code base every now and then for these keywords could result in finding problem areas that might otherwise go unnoticed.
What are some other tips you would give to someone looking to find problem areas in someone else’s code? Please share them below to get a conversation started. If you have any questions about building your software product or need help with your software project then feel free to contact us.
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at firstname.lastname@example.org. You can also connect with us on Twitter, Facebook, or LinkedIn.