This is the third post in a series about writing code for my co-workers. Here are parts one and two.
Navigability
In the previous posts, I wrote about code naming and clarity. Another factor which makes your code easier to maintain is code navigation. What I mean by code navigability is how easyy it is to find your way around the various classes contained in the project.
In Java, good code navigability is enforced by the compiler. That is:
- The name of the source file must be the same as the name of the class defined in it, and
- The directory structure where the source file is stored must reflect the package of the class.
So, for example, MyClass needs to be in a file MyClass.java, and if MyClass is declared in the package com.whatever, the file needs to be in the directory com/whatever. If you do not meet these terms, the compiler will spit out an error. (Note: if I remember correctly, this used to be a warning in the JDK 1.0 days, but I am not sure).
Unfortunately, .NET does not enforce these conditions. This means that you are able to save your code in any file and/or folder you want, and this have disastrous effect on navigability. You can still use your IDE of choice to find whatever you’re looking for, but it isn’t as simple as it could have been.
In order for your coworkers to find their way in your code, the best thing to do is simply to make the file name and type name identical, and to reflect sub-namespaces with subfolders. No matter how simple the type: even a two-valued enum gets its own file.
Note that with C# 2.0, we are going to get Partial Classes, and code navigability is going to get even worse: you have to find out in which of the two (three? four?) files that make up a class is that particular method you need to edit.